Posted: Mon Jun 17, 2019 22:28 Post subject: QOS issue (not working)
Firmware: DD-WRT v3.0-r39956 std (06/06/19)
I have a QOS configured through the GUI that is not functional. I have two netmask priorities where one subnet gets Maximum priority and another should get bulk. I have a machine (172.16.1.1) on the subnet that should be getting Bulk and one on the one that should be receiving Maximum (192.168.1.192). In other words when I download something at the same time the Bulk is not getting 5% of the bandwidth and instead sharing 50%. As you can see the rules are being added to the FILTER_IN. The thing I don't get is that the MARK xset is 0x35400 (192.168.1.192/26) and 0x37c00 (184.108.40.206/ which doesn't line up with the value returned by get_nfmark QOS 100 or get_nfmark QOS 40. I kind of don't understand how it works and how this is being generated or mapped.
Chain FILTER_IN (1 references)
pkts bytes target prot opt in out source destination
7083K 6639M CONNMARK 0 -- * * 0.0.0.0/0 0.0.0.0/0 CONNMARK restore
12541 1641K MARK 0 -- * * 192.168.1.192/26 0.0.0.0/0 mark match 0x0/0x7ffc00 MARK xset 0x35400/0x7ffc00
47 8137 MARK 0 -- * * 0.0.0.0/0 192.168.1.192/26 mark match 0x0/0x7ffc00 MARK xset 0x35400/0x7ffc00
628 69824 MARK 0 -- * * 220.127.116.11/8 0.0.0.0/0 mark match 0x0/0x7ffc00 MARK xset 0x37c00/0x7ffc00
1541 1701K MARK 0 -- * * 0.0.0.0/0 18.104.22.168/8 mark match 0x0/0x7ffc00 MARK xset 0x37c00/0x7ffc00
4426 724K FILTER_br2_IN 0 -- br2 * 0.0.0.0/0 0.0.0.0/0
2173K 1973M SVQOS_SVCS 0 -- * * 0.0.0.0/0 0.0.0.0/0 mark match 0x0/0x7ffc00
7083K 6639M CONNMARK 0 -- * * 0.0.0.0/0 0.0.0.0/0 CONNMARK save
7083K 6639M RETURN 0 -- * * 0.0.0.0/0 0.0.0.0/0
Posted: Wed Jun 19, 2019 18:04 Post subject: Re: QOS issue (not working)
I have another suspicion here. If I have an openvpn client running on tun1 interface then how will qos be able to operate properly on that given that my wan interface is ppp0. Just to give some context I have my guest network (172.16.1.0) being routed through the vpn client (tun1). If I add a netmask priority wouldn't it be queuing it against ppp0 and therefore the bulk priority would be missed by qos?