dd-wrt router firmware QoS troubleshooting

Question

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?

Answer 1

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.

Answer 2

I've noticed that a lot of people complain about QoS not working in DD-WRT, so they switch to Tomato instead. It works fine in Tomato (I use it). Tomato also has very nice graphs, which is useful for adjusting your QoS settings.

The downside to Tomato, compared to DD-WRT, is that it has less features, although there are a few mod builds which add certain things, like USB storage and OpenVPN. However, as Jeff Atwood mentioned below, it only supports Broadcom chipsets.

I use the Teddy Bear mod on my Netgear WNR3500L. I now use the Toastman mod, which is based on Teddy Bear, with more features and better default QoS classes which work for most people.

Personally, the only things that I am missing in Tomato is VLAN support and multi-SSID broadcast. (Toastman's mod has them both now, as well as Captive Portal for the secondary SSID).

Answer 3

I have found DD-WRT v24 sp2 build 15362 to be very stable on my Netgear WNDR3700 v1 BUT in spite a huge amount of time spent trying to setup both QoS and TCP Vegas (congestion control) neither mechanism appears to be working on this excellent firmware for inbound traffic (I have no need of outbound control as I do not use VOIP).

For example no matter what options (Mac Control, Netmask, Service Control) I use in my attempts to prioritize inbound video traffic and de-prioritize inbound bit torrent traffic nothing works. I have confirmed this with

• Telnet commands suggested for confirming QoS operation
• TCP Vegas

Bottom Line: Use DD-WRT if you want all the other features (particularly broadcast of muliple SSIDs) but use Tomato if you have an applicable chipset ( Tomato is not available for the Atheros based WNDR3700) and like its QoS features.

Answer 4

I noticed the same thing. I can't find the exact post now, but digging through the forums one of the devs stated that QoS as it is works great on uploads, not so much on downloads. The reasoning behind it is that the router has control of the traffic going out of the network (uplink), but not the traffic going in since it has no control over the incoming flux of data.

I know you're not a huge fan of browsing through forum posts, but you may want to post your questions there.