ESFQ using hash 'ctnatchg'

[GoogleCodeExporter]

What version of the product are you using?
RT-N10U
1.9.2.7-rtn-r3661

Please provide any additional information below.

I want to use esfq with hash 'ctnatchg', yet it always fall back to 'classic' 
without any warnings

this is what I found in dmesg:
ESFQ: Conntrack hash types disabled in kernel config. Falling back to classic.

it would be best to enable (include) that function, or include it as a module
without 'ctnatchg', using esfq is pretty much meaningless (equal using the old 
sfq version)

Original issue reported on code.google.com by t27049...@gmail.com on 4 Dec 2011 at 5:57

[GoogleCodeExporter]

It requires CONFIG_NET_SCH_SFQ_NFCT=y and cannot be compiled as separate 
module. i.e. this increase size of either kernel, or sfq.ko module. Size 
penalty approx. 0.5K

Please explain for which purpose you are trying to use 'ctnatchg' hash.

Original comment by lly.dev on 12 Dec 2011 at 12:25

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

quote from esfq README: (http://fatooh.org/esfq-2.6/current/README)

Consider several workstations behind a router that uses SNAT or masquerade to
change the source address of outgoing packets; on the router, the inside
(LAN) interface is eth0 and the outside (WAN) interface is eth1. All packets
leaving eth1 will have eth1's IP address, so hashing by source IP is useless.
Instead, use ctorigsrc, which will correspond to the workstations' IPs.

"Conntrack NAT change," for lack of a better name. This is a combination of
ctorigsrc and ctreplsrc that is useful when a local host is configured to
accept incoming connections (via DNAT "port forwarding"), but outgoing
traffic must be shaped regardless of which host initiated the connection.
Consider this example:

   local host  = 10.0.0.2
   NAT router  = 1.2.3.4
   remote host = 87.65.43.21

   <outgoing connection>
   ctorigsrc = 10.0.0.2
   ctorigdst = 87.65.43.21
   ctreplsrc = 87.65.43.21
   ctrepldst = 1.2.3.4

   <incoming connection>
   ctorigsrc = 87.65.43.21
   ctorigdst = 1.2.3.4
   ctreplsrc = 10.0.0.2
   ctrepldst = 87.65.43.21

The logic for ctnatchg is simple. If ctorigdst == ctreplsrc, then the
connection is outgoing, so hash by ctorigsrc. Otherwise, the connection
is incoming, so hash by ctreplsrc.

In short, 'ctnatchg' hash have better fairness under NAT environment

Original comment by t27049...@gmail.com on 13 Dec 2011 at 6:34

[GoogleCodeExporter]

I asked about your specific solution, not generic esfq capabilities, since 
nobody ask for this feature before.

Original comment by lly.dev on 14 Dec 2011 at 8:21

• Changed state: Accepted

[GoogleCodeExporter]

I am doing traffic shaping on my router
The router have about 5~10 clients. The outgoing bandwidth is limited, and some 
of the users are running P2P which takes away much bandwidth
My traffic shaping script is based on 'wshaper script', with sfq replaced by 
esfq and some little modifications

In the example above (and in my network), if esfq is attached on WAN interface 
and using 'classic' hash, (because the router is performing SNAT) src ip will 
always be the NAT router (1.2.3.4). To ensure each user fairness, the correct 
src ip should be set to local host (10.0.0.2)

For incoming connections, like 'ctnatchg' is doing, is what I intended to do

Original comment by t27049...@gmail.com on 20 Dec 2011 at 4:30

[GoogleCodeExporter]

Done in r3694.

Best of all if you will share your scripts with community - here or at 
wl500g.info forum.

Original comment by lly.dev on 20 Dec 2011 at 5:57

• Changed state: Done