QoS set to WAN sends uplink traffic to downlink queue

[phuzi0n]

When QoS is set to use the WAN port, there are two iptables rules created that send traffic to the imq0 device. One is in the PREROUTING chain that matches traffic coming in from br0 (uplink!) and the other is in the FORWARD chain that matches traffic coming in from the WAN port (downlink). This makes it so that any upstream traffic will eat away from the available bandwidth in the downlink queue and downstream traffic will be slowed more than it should be. This also affects users with NAS's running on their router because traffic from the LAN to the NAS will be put into the downlink queue.

Here is evidence of the two IMQ rules from a fresh system with QoS enabled and nothing else configured (ie. no custom firewall commands or anything).

root@DD-WRT:~# iptables -t mangle -vnL
Chain PREROUTING (policy ACCEPT 12932 packets, 12M bytes)
 pkts bytes target     prot opt in     out     source               destination 
 5740 3515K IMQ        0    --  br0    *       0.0.0.0/0            0.0.0.0/0           IMQ: todev 0
 7192 8752K SVQOS_IN   0    --  eth1   *       0.0.0.0/0            0.0.0.0/0   
    0     0 MARK       0    --  *      *       0.0.0.0/0            0.0.0.0/0           MAC 00:00:00:00:00:00 MARK set 0x1e
    0     0 MARK       0    --  *      *       0.0.0.0/0            0.0.0.0/0           MAC 00:55:00:00:00:00 MARK set 0x1e
12932   12M CONNMARK   0    --  *      *       0.0.0.0/0            0.0.0.0/0           CONNMARK save

Chain INPUT (policy ACCEPT 111 packets, 19901 bytes)
 pkts bytes target     prot opt in     out     source               destination 

Chain FORWARD (policy ACCEPT 12796 packets, 12M bytes)
 pkts bytes target     prot opt in     out     source               destination 
 7191 8752K IMQ        0    --  eth1   *       0.0.0.0/0            0.0.0.0/0           IMQ: todev 0
 

IMO there should be a single rule in PREROUTING that matches traffic coming in from the WAN interface and sends it to imq0; the existing FORWARD rule won't match traffic destined to the router itself.

Users can fix it themselves by adding the follow commands to the their firewall scripts (admin->commands->save firewall) until it is fixed. Due to bug #1432 this fix won't work on Broadcom k2.6 builds so someone will have to rewrite it for BCM k2.6...

WANIF=`get_wanface`
iptables -t mangle -I PREROUTING -i $WANIF -j IMQ --todev 0
iptables -t mangle -D PREROUTING -i br0 -j IMQ --todev 0
iptables -t mangle -D FORWARD -i $WANIF -j IMQ --todev 0

Afterwords the chains will look something like this (WAN port is hardware dependent so it will differ).

root@DD-WRT:~# iptables -t mangle -vnL
Chain PREROUTING (policy ACCEPT 13888 packets, 12M bytes)
 pkts bytes target     prot opt in     out     source               destination 
    0     0 IMQ        0    --  eth1   *       0.0.0.0/0            0.0.0.0/0           IMQ: todev 0
 7209 8754K SVQOS_IN   0    --  eth1   *       0.0.0.0/0            0.0.0.0/0   
    0     0 MARK       0    --  *      *       0.0.0.0/0            0.0.0.0/0           MAC 00:00:00:00:00:00 MARK set 0x1e
    0     0 MARK       0    --  *      *       0.0.0.0/0            0.0.0.0/0           MAC 00:55:00:00:00:00 MARK set 0x1e
13888   12M CONNMARK   0    --  *      *       0.0.0.0/0            0.0.0.0/0           CONNMARK save

Chain INPUT (policy ACCEPT 1066 packets, 184K bytes)
 pkts bytes target     prot opt in     out     source               destination 

Chain FORWARD (policy ACCEPT 12796 packets, 12M bytes)
 pkts bytes target     prot opt in     out     source               destination 

[SpyrosB]

The fix worked fine on Broadcom K2.6 WRT320N DD-WRT v24-sp2 (06/09/10) big - build 14584M NEWD-2 K2.6 Eko

Rules are deleted but

nvram get wan_iface

reports vlan2 and im using PPPoE so i used this code

iptables -t mangle -I PREROUTING -i ppp0 -j IMQ --todev 0
iptables -t mangle -D PREROUTING -i br0 -j IMQ --todev 0
iptables -t mangle -D FORWARD -i ppp0 -j IMQ --todev 0

now chains look like this

Chain PREROUTING (policy ACCEPT 23M packets, 12G bytes)
 pkts bytes target     prot opt in     out     source               destination         
 1325  117K IMQ        0    --  ppp0   *       0.0.0.0/0            0.0.0.0/0           IMQ: todev 0 
  11M 4483M SVQOS_IN   0    --  ppp0   *       0.0.0.0/0            0.0.0.0/0           

Chain INPUT (policy ACCEPT 179K packets, 17M bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain FORWARD (policy ACCEPT 42M packets, 23G bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 55670 packets, 11M bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain POSTROUTING (policy ACCEPT 42M packets, 23G bytes)
 pkts bytes target     prot opt in     out     source               destination         
  13M 7504M SVQOS_OUT  0    --  *      ppp0    0.0.0.0/0            0.0.0.0/0           

before running the fix they looked like this

Chain PREROUTING (policy ACCEPT 23M packets, 12G bytes)
 pkts bytes target     prot opt in     out     source               destination         
  13M 7486M IMQ        0    --  br0    *       0.0.0.0/0            0.0.0.0/0           IMQ: todev 0 
  11M 4480M SVQOS_IN   0    --  ppp0   *       0.0.0.0/0            0.0.0.0/0           

Chain INPUT (policy ACCEPT 178K packets, 17M bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain FORWARD (policy ACCEPT 42M packets, 23G bytes)
 pkts bytes target     prot opt in     out     source               destination         
  11M 4476M IMQ        0    --  ppp0   *       0.0.0.0/0            0.0.0.0/0           IMQ: todev 0 

Chain OUTPUT (policy ACCEPT 55385 packets, 11M bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain POSTROUTING (policy ACCEPT 42M packets, 23G bytes)
 pkts bytes target     prot opt in     out     source               destination         
  13M 7467M SVQOS_OUT  0    --  *      ppp0    0.0.0.0/0            0.0.0.0/0           

[matherren]

WANIF=`nvram get wan_iface` #this may need to be wan_ifname instead
iptables -t mangle -I PREROUTING -i $WANIF -j IMQ --todev 0
iptables -t mangle -D PREROUTING -i br0 -j IMQ --todev 0
iptables -t mangle -D FORWARD -i $WANIF -j IMQ --todev 0

this fix dont work in my router using (eko v24-sp2 std svn: 14583)

rc_firewall or rc_command run this fix before iptables (dd-wrt) set the main rules

[SpyrosB]

Replying to matherren:

WANIF=`nvram get wan_iface` #this may need to be wan_ifname instead
iptables -t mangle -I PREROUTING -i $WANIF -j IMQ --todev 0
iptables -t mangle -D PREROUTING -i br0 -j IMQ --todev 0
iptables -t mangle -D FORWARD -i $WANIF -j IMQ --todev 0

this fix dont work in my router using (eko v24-sp2 std svn: 14583)

rc_firewall or rc_command run this fix before iptables (dd-wrt) set the main rules

Check this

Commands in rc_firewall script are not applied in QoS

​http://svn.dd-wrt.com:8000/dd-wrt/ticket/1601

[phuzi0n]

The wan_iface variable is functioning differently in current builds so the script has changed to use get_wanface instead as per #1787.

[iWill]

Workaround: ​http://svn.dd-wrt.com:8000/ticket/1601#comment:7

[phuzi0n]

Fixed in r16682

[DavisNT]

I used workaround script in original post, it didn't work in firewall script, but did work in startup script (this is because in my case firewall script is called before QoS entries are "added to iptables"). In fact in firewall script this introduced even worse slowing down of my traffic (because it added PREROUTING entry without removing FORWARD entry). My router: Linksys WRT54G2 with DD-WRT 15230 micro plus ssh.