What's new

Hairpin translated traffic counted in QOS

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

norgoe

New Around Here
Hi,

I am using an RT-AC87U with latest merlin 380.57.
I recently was wandering why the up- and download to my owncloud (hosted at home on a quadcore xeon) was never exceeding 5MBit/s when accessed using the global dns name. Using the local name of the server does not impose this limit - but as this would include changing mutliple clients when leaving/returning home, it is no valid option to change the client configs. Instead the "hairpin counting bug" should be fixed.

Seems like the reason is the activated Traditional QOS limiting the upload traffic to the 5MBit my cable network provides and the download traffic to 50MBit.
While this QOS should boost performance when the link is saturated it momentarily does the opposite when hairpin translation is involved. Checking the realtime traffic stats it is obvious, that the hairpin translated traffic - while acutally never leaving the router on the link to the cable modem - is counted in the up- and downstream direction.
When I disable QOS or raise the up- and downstream limits from 5/50 mbits to 100/100 mbits the transfer rates increase significantly. So it is obvious that with the counting bug currently QOS harms when hairpin translation is involved. Needless to say, that the AC87U is not stressed at all by those few nat packets/seconds that are hairpin translated.

It would be nice to see a patch for this behaviour soon.

Thanks
Norbert
 
BTW:
Asus won't even try to reproduce the problem with a config file for their last firmware as I posted here that the problem also exists in Merlin.
As I used 3rd party software on the router the support is taking the position of "the problem is caused by 3rd party software"...
 
Ok, I debugged the problem on the router - thanks to merlins ssh access.

As guessed it's a stupid misconfiguration by asus. They already have a mangle rule whish should bypass the throttling qdis for haripin traffic - but it's inserted at the end of the chain. If any other qos rule matches (and all default rules at least match the ip as they are 0.0.0.0/0 rules) the hairpin rule is never met.

Here is the output of the false ruleset of "iptables -t mangle -L QOSO --line-numbers -nv":
Chain QOSO (3 references)
num pkts bytes target prot opt in out source destination
1 0 0 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 mark match 0xb400
2 4864 4961K CONNMARK all -- * * 0.0.0.0/0 0.0.0.0/0 CONNMARK restore mask 0x7
3 0 0 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 connmark match ! 0x0/0xff00
4 0 0 CONNMARK tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 connbytes 0:524287 connbytes mode bytes connbytes direction both CONNMARK set-return 0x2/0x7
5 0 0 RETURN tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 connbytes 0:524287 connbytes mode bytes connbytes direction both
6 572 685K CONNMARK tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:443 connbytes 0:524287 connbytes mode bytes connbytes direction both CONNMARK set-return 0x2/0x7
7 572 685K RETURN tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:443 connbytes 0:524287 connbytes mode bytes connbytes direction both
8 628 32656 CONNMARK tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 connbytes 524288 connbytes mode bytes connbytes direction both CONNMARK set-return 0x4/0x7
9 628 32656 RETURN tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 connbytes 524288 connbytes mode bytes connbytes direction both
10 997 2985K CONNMARK tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:443 connbytes 524288 connbytes mode bytes connbytes direction both CONNMARK set-return 0x4/0x7
11 997 2985K RETURN tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:443 connbytes 524288 connbytes mode bytes connbytes direction both
12 0 0 CONNMARK tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 25,465,563,587,110,119,143,220,993,995 CONNMARK set-return 0x3/0x7
13 0 0 RETURN tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 25,465,563,587,110,119,143,220,993,995
14 0 0 CONNMARK udp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 25,465,563,587,110,119,143,220,993,995 CONNMARK set-return 0x3/0x7
15 0 0 RETURN udp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 25,465,563,587,110,119,143,220,993,995
16 0 0 CONNMARK tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 53,37,123,3455 connbytes 0:10239 connbytes mode bytes connbytes direction both CONNMARK set-return 0x1/0x7
17 0 0 RETURN tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 53,37,123,3455 connbytes 0:10239 connbytes mode bytes connbytes direction both
18 12 939 CONNMARK udp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 53,37,123,3455 connbytes 0:10239 connbytes mode bytes connbytes direction both CONNMARK set-return 0x1/0x7
19 12 939 RETURN udp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 53,37,123,3455 connbytes 0:10239 connbytes mode bytes connbytes direction both
20 2 121 CONNMARK tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 20:23,6571,681:6901 connbytes 10240 connbytes mode bytes connbytes direction both CONNMARK set-return 0x4/0x7
21 2 121 RETURN tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 20:23,6571,681:6901 connbytes 10240 connbytes mode bytes connbytes direction both
22 0 0 CONNMARK udp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 20:23,6571,681:6901 connbytes 10240 connbytes mode bytes connbytes direction both CONNMARK set-return 0x4/0x7
23 0 0 RETURN udp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 20:23,6571,681:6901 connbytes 10240 connbytes mode bytes connbytes direction both
24 0 0 CONNMARK tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 connbytes 0:10239 connbytes mode bytes connbytes direction both CONNMARK set-return 0x1/0x7
25 0 0 RETURN tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 connbytes 0:10239 connbytes mode bytes connbytes direction both
26 0 0 CONNMARK all -- * * 0.0.0.0/0 224.0.0.0/4 CONNMARK set-return 0x6/0x7
27 0 0 RETURN all -- * * 0.0.0.0/0 224.0.0.0/4
28 2620 1255K CONNMARK all -- * * 0.0.0.0/0 192.168.10.0/24 CONNMARK set-return 0x6/0x7
29 2620 1255K RETURN all -- * * 0.0.0.0/0 192.168.10.0/24
30 33 3027 CONNMARK all -- * * 0.0.0.0/0 0.0.0.0/0 CONNMARK set-return 0x4/0x7
31 33 3027 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0

My local IP-range is 192.168.10.0/24.
Rules 28 and 29 are the ones that should work but are far to low.
Moving the rules to Lines 4 and 5 solves the hairpin throttling problem.

iptables -t mangle -I QOSO 4 -d 192.168.10.0/24 -j CONNMARK --set-return 0x6/0x7
iptables -t mangle -I QOSO 5 -d 192.168.10.0/24 -j RETURN

I also send this information to asus and asked them to forward it to the firmware developers, but in the meantime:

How can I add these two iptables rules to the router to get them set after reboot?
Enable JFFS in Admin/System Settings
Create the script /jffs/scripts/services-start containing:
#!/bin/sh
sleep 30
/usr/sbin/iptables -t mangle -I QOSO 4 -d 192.168.10.0/24 -j CONNMARK --set-return 0x6/0x7
/usr/sbin/iptables -t mangle -I QOSO 5 -d 192.168.10.0/24 -j RETURN

And remember to change 192.168.10.0/24 to your local ip-range.
 
Last edited:

Similar threads

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top