DD-WRT – Troubleshooting QoS on Router Firmware

dd-wrtqos

I've been using the dd-wrt firmware on my router and I like it a lot!

But — I'm not sure the quality of service (QoS) is working on it. I have it set up as follows:

  • http, port 80 — Premium
  • bittorrent, port 6969 — Bulk
  • https, port 443 — Premium
  • dns, port 53 — Premium

Per the QoS documentation, these levels are:

bandwidth is allocated based on the following percentages of uplink and downlink values for each class:

  • Exempt: 100mbps – ignores global limits.
  • Premium: 75% – 100%
  • Express: 15% – 100%
  • Standard: 10% – 100%
  • Bulk: 1.5% – 100%

This doesn't entirely seem to work, though — with busy torrents going I get major pauses in my web browsing which sucks!

The QoS documentation gives some steps to check the QoS …

What you'll be interested to look at will be the first set of source and destination IP, including the port numbers. Next the presence of l7proto and the "mark" field. The entries indicate the current live connection QoS priority applied on them based on the "mark" field. The "mark" values correspond to the following

  • Exempt: 100
  • Premium: 10
  • Express: 20
  • Standard: 30
  • Bulk: 40
  • (no QoS matched): 0

You may see "mark=0" for some l7proto service even though they are in configured in the list of QoS rules. This may mean that the layer 7 pattern matching system didn't match a new or changed header for that protocol. Custom service on port matches will usually take care of these.

On port 6969 (bittorrent) I see a weird mixture of stuff with mark=0 and mark=40 like so

cat /proc/net/ip_conntrack

udp  17 105 src=98.162.182.42 dst=1.2.3.4 sport=64512 dport=6969 packets=3 bytes=290 src=10.0.0.2 dst=98.162.182.42 sport=6969 dport=64512 packets=4 bytes=202 [ASSURED] mark=0 secmark=0 use=1
tcp  6 117 TIME_WAIT src=98.248.173.174 dst=1.2.3.4 sport=51114 dport=6969 packets=12 bytes=704 src=10.0.0.2 dst=98.248.173.174 sport=6969 dport=51114 packets=10 bytes=440 [ASSURED] mark=40 secmark=0 use=1
tcp  6 598 ESTABLISHED src=165.132.128.201 dst=1.2.3.4 sport=57218 dport=6969 packets=8024 bytes=9919881 src=10.0.0.2 dst=165.132.128.201 sport=6969 dport=57218 packets=4211 bytes=239607 [ASSURED] mark=0 secmark=0 use=1
tcp  6 586 ESTABLISHED src=68.46.9.24 dst=1.2.3.4 sport=64688 dport=6969 packets=6 bytes=490 src=10.0.0.2 dst=68.46.9.24 sport=6969 dport=64688 packets=8 bytes=944 [ASSURED] mark=40 secmark=0 use=1
udp 17 45 src=222.254.228.38 dst=1.2.3.4 sport=25438 dport=6969 packets=5 bytes=454 src=10.0.0.2 dst=222.254.228.38 sport=6969 dport=25438 packets=3 bytes=154 [ASSURED] mark=0 secmark=0 use=1

( full file visible at http://pastebin.com/AZE6EtWm )

I've been playing around with this log for a little while and I can't see any patterns!

Why is some port 6969 bittorrent traffic tagged mark=0 (not matched) by dd-wrt's QoS while others are tagged mark=40 (Bulk) .. any ideas?

Best Answer

Though it only shapes outgoing traffic, you may find this excellent QoS script (mirror on pastebin) on Alex Rice's blog useful. It's been through several authors and incarnations. Be certain to set UPLINK as well as DEV correctly. For me the default value for DEV was incorrect, use the commented $(nvram get wan_ifname) instead, or the correct value from executing nvram get wan_iframe via SSH.

Also rather than using it, you may duplicate its configuration within the QoS GUI. You'll see it uses 1024:65535 for bulk traffic, with the other settings (80,22,3389, etc.) taking precendence. The script works well for me, and uses HFSC as recommended.

Also, if you don't use the script, you may encounter relevant bugs for your version.

For instance: QoS set to WAN sends uplink traffic to downlink queue
Then realize this patch fails, because: Commands in rc_firewall script are not applied in QoS

You can workaround the problem with a script that executes after rc_firewall as noted in the ticket. I personally ended up enabling JFFS and placing the script with the fix in /jffs/etc/config/qos.ipup, same as mentioned.

I found it convenient to use KiTTY and WinSCP. You can SSH into the router with KiTTY to troubleshoot/verify as in the first ticket, and launch straight into file browsing on the router with the Start WinSCP command under KiTTY's top left icon. If this fails (router isn't running SFTP by default) you can enable FTP and connect manually, or simply add the file with Unix commands. Remember to set the owner execute permission on the script.

Related Question