Opened 3 years ago

Closed 3 months ago

#1560 closed (fixed)

Applying QoS sometimes results in bad iptables chains

Reported by: phuzi0n Owned by:
Keywords: Cc: elsdoerfer

Description (last modified by phuzi0n)

Sometimes when you change settings on the QoS page and Apply them, the iptables rules will not be created properly. This particularly affect the SVQOS_IN and SVQOS_OUT chains. It has been occurring for years and other users have reported it recently (within the last month or so) but it doesn't always occur and I was not able to reproduce it while investigating other QoS problems. If anyone is able to reproduce it please provide more details. Until then please ignore this ticket devs.

If you suspect that you're encountering this bug then connect to the router with telnet/ssh and get the output from this command and post it as a comment here.

iptables -t mangle -vnL

Change History (6)

comment:1 Changed 3 years ago by phuzi0n

  • Description modified (diff)

comment:2 Changed 3 years ago by SpyrosB

I have encountered this problem many times and i stopped using the web interface to set up QoS because of this. Instead of using the web interface now i use a script. You can see a reproduction of the problem here

http://www.dd-wrt.com/phpBB2/viewtopic.php?p=437349#437349

Code:
root@DD-WRT:~# iptables -t mangle -v -L -n
Chain PREROUTING (policy ACCEPT 6959 packets, 2625K bytes)
 pkts bytes target     prot opt in     out     source               destination         
 4397 2357K IMQ        0    --  br0    *       0.0.0.0/0            0.0.0.0/0           IMQ: todev 0
 4399 2357K SVQOS_IN   0    --  br0    *       0.0.0.0/0            0.0.0.0/0           

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

Chain FORWARD (policy ACCEPT 12718 packets, 3740K bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 549 packets, 64401 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain POSTROUTING (policy ACCEPT 21450 packets, 8182K bytes)
 pkts bytes target     prot opt in     out     source               destination         
 2995  321K SVQOS_OUT  0    --  *      br0     0.0.0.0/0            0.0.0.0/0           

Chain SVQOS_IN (1 references)
 pkts bytes target     prot opt in     out     source               destination         
 4392 2356K CONNMARK   0    --  *      *       0.0.0.0/0            0.0.0.0/0           CONNMARK restore
    0     0 RETURN     0    --  *      *       0.0.0.0/0            0.0.0.0/0           MARK match !0x0
 4388 2356K CONNMARK   0    --  *      *       0.0.0.0/0            0.0.0.0/0           CONNMARK restore
    0     0 RETURN     0    --  *      *       0.0.0.0/0            0.0.0.0/0           MARK match !0x0
 3781 2295K MARK       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpts:1024:65535 MARK match 0x0 MARK set 0x28
  559 56200 MARK       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp spts:1024:65535 MARK match 0x0 MARK set 0x28
    0     0 MARK       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           MARK match 0x0 ipp2p v0.8.2 --bit MARK set 0x28
    0     0 MARK       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpts:1024:65535 MARK match 0x0 MARK set 0x28
    0     0 MARK       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp spts:1024:65535 MARK match 0x0 MARK set 0x28
    0     0 MARK       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           MARK match 0x0 ipp2p v0.8.2 --bit MARK set 0x28

Chain SVQOS_OUT (1 references)
 pkts bytes target     prot opt in     out     source               destination         
 2995  321K CONNMARK   0    --  *      *       0.0.0.0/0            0.0.0.0/0           CONNMARK restore
    0     0 RETURN     0    --  *      *       0.0.0.0/0            0.0.0.0/0           MARK match !0x0
 2991  320K CONNMARK   0    --  *      *       0.0.0.0/0            0.0.0.0/0           CONNMARK restore
    0     0 RETURN     0    --  *      *       0.0.0.0/0            0.0.0.0/0           MARK match !0x0
 2943  317K MARK       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpts:1024:65535 MARK match 0x0 MARK set 0x28
    0     0 MARK       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp spts:1024:65535 MARK match 0x0 MARK set 0x28
    0     0 MARK       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           MARK match 0x0 ipp2p v0.8.2 --bit MARK set 0x28
    0     0 MARK       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpts:1024:65535 MARK match 0x0 MARK set 0x28
    0     0 MARK       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp spts:1024:65535 MARK match 0x0 MARK set 0x28
    0     0 MARK       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           MARK match 0x0 ipp2p v0.8.2 --bit MARK set 0x28 

comment:3 Changed 3 years ago by SpyrosB

After some testing i discovered that the issue occurs when all bittorent L7 filters are selected through the web interface. If you select bittorent, bt, bt1, bt2 and bt3 L7 filters this will result in bad iptables chains. This happens because the code generates all the needed bittorrent L7 filters if you just select "bittorrent"

comment:5 Changed 3 years ago by elsdoerfer

  • Cc elsdoerfer added

comment:6 Changed 3 months ago by tatsuya46

  • Resolution set to fixed
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.