That gave me an idea. Just added this line in /etc/rc.local
/etc/init.d/firewall restart
It works now! 
2 Likes
SO one of the issues I see is that pppoe-wan is a transient device that might come and go. sqm-scripts uses hotplug scripts to stop and start its instances if an interface disappears or re-appears. Integrating the whole firewall.user script into the sqm-scripts framework (and moving it out of the firewall) might help to make things more stable...
@AlanDias17can you show me the output of
ifconfig
Kinda busy rn but I'll reply you guys asap 
But even when I disable SQM it happens no matter what. Wait I'll update you with my another post..
Update: Exact issue but solution doesn't work anymore. PPPoE "unknown error (USER_REQUEST)". Problem persists.
@dlakelan @hisham2630 @moeller0
I found something intresting. Remember this router doesn't have wlan (wifi module) instead I've connected an another router as AP to this main router (via lan ofc).
Scenario 1: Apply single instance SQM on pppoe-wan on both ingress & egress. At load, web browsing sucks, videos buffer. In short SQM doesn't work.
Scenario 2: (Just like I've had done in past) Apply two instances of SQM on both pppoe-wan & br-lan only on egress. At load, web browsing works, videos don't buffer etc. In short SQM works as intended.
root@OpenWrt:~# brctl show
bridge name bridge id STP enabled interfaces
br-lan 7fff.6466b39a75ca no eth1.1
root@OpenWrt:~# ifconfig
br-lan Link encap:Ethernet HWaddr 64:56:B3:9B:75:CA
inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:700661 errors:0 dropped:327 overruns:0 frame:0
TX packets:858953 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:126105552 (120.2 MiB) TX bytes:1065939211 (1016.5 MiB)
eth0 Link encap:Ethernet HWaddr 64:56:B3:9B:75:CB
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:999110 errors:0 dropped:60994 overruns:0 frame:0
TX packets:697102 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1181661770 (1.0 GiB) TX bytes:138999875 (132.5 MiB)
Interrupt:4
eth1 Link encap:Ethernet HWaddr 64:56:B3:9B:75:CA
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:700695 errors:0 dropped:5 overruns:0 frame:0
TX packets:858960 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:138720182 (132.2 MiB) TX bytes:1069375727 (1019.8 MiB)
Interrupt:5
eth1.1 Link encap:Ethernet HWaddr 64:56:B3:9B:75:CA
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:700678 errors:0 dropped:9 overruns:0 frame:0
TX packets:858953 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:126106334 (120.2 MiB) TX bytes:1065939211 (1016.5 MiB)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:299 errors:0 dropped:0 overruns:0 frame:0
TX packets:299 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1
RX bytes:26113 (25.5 KiB) TX bytes:26113 (25.5 KiB)
pppoe-wan Link encap:Point-to-Point Protocol
inet addr:172.14.11.212 P-t-P:103.39.28.6 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1480 Metric:1
RX packets:921754 errors:0 dropped:0 overruns:0 frame:0
TX packets:696736 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:1156074551 (1.0 GiB) TX bytes:123635606 (117.9 MiB)
Scenario 3: Use above veth method. Two SQM instances on both pppoe-wan & veth0 egress only. At load, web browsing works, videos don't buffer etc. In short SQM works as intended. Same as scenario 2. I get A+ A+ A+ in both scenarios (Even on wireless clients).
root@OpenWrt:~# brctl show
bridge name bridge id STP enabled interfaces
br-lan 7fff.6466b39a75ca no eth1.1
veth1
root@OpenWrt:~# ifconfig
br-lan Link encap:Ethernet HWaddr 64:56:B3:9B:75:CA
inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:4691 errors:0 dropped:325 overruns:0 frame:0
TX packets:3698 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:467198 (456.2 KiB) TX bytes:971306 (948.5 KiB)
eth0 Link encap:Ethernet HWaddr 64:56:B3:9B:75:CB
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:4280 errors:0 dropped:1859 overruns:3392909 frame:0
TX packets:2652 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1062823 (1.0 MiB) TX bytes:473553 (462.4 KiB)
Interrupt:4
eth1 Link encap:Ethernet HWaddr 64:56:B3:9B:75:CA
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:5895 errors:0 dropped:2 overruns:0 frame:0
TX packets:4712 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:875319 (854.8 KiB) TX bytes:1536611 (1.4 MiB)
Interrupt:5
eth1.1 Link encap:Ethernet HWaddr 64:56:B3:9B:75:CA
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:5890 errors:0 dropped:7 overruns:0 frame:0
TX packets:4710 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:768602 (750.5 KiB) TX bytes:1517633 (1.4 MiB)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:789 errors:0 dropped:0 overruns:0 frame:0
TX packets:789 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1
RX bytes:66926 (65.3 KiB) TX bytes:66926 (65.3 KiB)
pppoe-wan Link encap:Point-to-Point Protocol
inet addr:172.14.11.212 P-t-P:103.39.28.6 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1480 Metric:1
RX packets:1126 errors:0 dropped:0 overruns:0 frame:0
TX packets:1277 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:687284 (671.1 KiB) TX bytes:303986 (296.8 KiB)
veth0 Link encap:Ethernet HWaddr 8A:12:44:7D:B5:67
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2745 errors:0 dropped:207 overruns:0 frame:0
TX packets:977 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:741545 (724.1 KiB) TX bytes:544437 (531.6 KiB)
veth1 Link encap:Ethernet HWaddr 86:AE:96:17:DE:20
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:977 errors:0 dropped:0 overruns:0 frame:0
TX packets:2745 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:544437 (531.6 KiB) TX bytes:741545 (724.1 KiB)
So altogether, my question is if my main router doesn't have wlan then does it mean that I don't need to use veth method? Bcz in scenario 2 it seems like packets are geting queued in br-lan with DSCP tags. What do you guys think?
Thats right! the purpose of the veth is to handle the case where you have two ways that packets can leave the router headed towards your LAN. if you just have a wired router, you don't need a br-lan at all. just change the LAN interface to use eth1.1 as the physical interface, and put the SQM instance on that.
2 Likes
I unfortunately, had not remembered that, good catch.
Well, yes as expected, bridge interfaces are special...
I am still amazed that that works at all. In my cursory testing (albeit with wifi in the bridge) that never worked well at all, as for a bridge ingress and egress are not that well defined...
Yes that is the sane approach using veths to avoid "crossing the bridge" 
Double PLUS one
1 Like
Well the whole general setup is like this,
@moeller0 I believe if main router had only one wired connection i.e. only wireless AP & from that lan devices + wifi devices then here veth is not needed. But the setup above I require veth don't I? Does eth1.1 refer all physical lan ports?
yes, change your LAN to not be a bridge, but just be eth1.1 and put an SQM on its egress and on the egress of pppoe... and that will work fine.
1 Like
Okay thanks
1 Like
I actually recommend everyone these days to buy wired routers and separate APs. This is one reason 
1 Like
Well the only reason I did this setup bcz the other router isn't compatible to install openwrt firmware but I got this from old stock, fixed it made it functional & installed this firm. Otherwise I'd just buy a new one & go with veth method srsly. It's just I just got into Linux & have been learning stuffs from you gentlemen 
The only issue with this device is that it's a 4MB/32MB device and that isn't really supported anymore. Technically it seems to work for you, but plan to upgrade soon. When you do, consider sticking with the architecture of a wired router and a wifi AP.
If I had anything less than 300/300 Mbps these days I'd probably buy a TP-Link sg108e switch and a RPi 4 as my router.
For more than 300/300 I'd buy an x86 like the Odroid H2 and the switch.
Yes I totally agree on this.
That reminds me of EdgeRouter. Hope they add CAKE option in sqm. Heard OpenWrt firmware also works in it. So I might give it a try on this soon. Also RPi 4 100% it's must.
I have EdgeRouter-X-SFP, CAKE was working until version 1.10.8, but i think it will work with version 2 too.
Yeah, i didn't tried that yet, but the problem is that it's not easy to get back to stock firmware, but i think there's a method now!
good luck and let me know, i liked the stock firmware configuration and DPI, that's why I'm sticking to it.
Sure I'll!
Also @hisham2630 do you know anything about this problem?
iptables v1.6.2: Couldn't load match `hashlimit':No such file or directory
When firewall starts this log shows up:
Warning: Section @zone[1] (wan) cannot resolve device of network 'wan6'
* Flushing IPv4 filter table
* Flushing IPv4 nat table
* Flushing IPv4 mangle table
* Flushing conntrack table ...
* Populating IPv4 filter table
* Rule 'Allow-DHCP-Renew'
* Rule 'Allow-Ping'
* Rule 'Allow-IGMP'
* Rule 'Allow-IPSec-ESP'
* Rule 'Allow-ISAKMP'
* Forward 'lan' -> 'wan'
* Zone 'lan'
* Zone 'wan'
* Populating IPv4 nat table
* Zone 'lan'
* Zone 'wan'
* Populating IPv4 mangle table
* Zone 'lan'
* Zone 'wan'
* Set tcp_ecn to off
* Set tcp_syncookies to on
* Set tcp_window_scaling to on
* Running script '/etc/firewall.user'
iptables v1.6.2: Couldn't load match `hashlimit':No such file or directory
Try `iptables -h' or 'iptables --help' for more information.
* Running script '/usr/share/miniupnpd/firewall.include'
This is the syntax:
iptables -t mangle -A dscp_mark -p udp -m hashlimit --hashlimit-name udp_high_prio --hashlimit-above 115/sec --hashlimit-burst 50 --hashlimit-mode srcip,srcport,dstip,dstport -j CONNMARK --set-mark 0x55 -m comment --comment "connmark for udp"
From quick google search I yielded that it has do with iptable.
P.S. yes I've installed both necessary modules.
iptables-mod-hashlimit
kmod-ipt-hashlimit
To see loaded iptable modules I entered:
root@OpenWrt:~# cat /proc/net/ip_tables_matches
time
statistic
state
quota
pkttype
owner
mac
limit
helper
conntrack
conntrack
conntrack
connlimit
connbytes
comment
addrtype
connmark
mark
icmp
tcpmss
recent
recent
multiport
length
iprange
ttl
hashlimit
hashlimit
ecn
tos
dscp
addrtype
set
set
set
set
set
udplite
udp
tcp
hashlimit is loaded so what's the deal here? Any help?
What will happen if you change -A dscp_mark to -A POSTROUTING ?
also try to re install module
In kernel config I changed CONFIG_NETFILTER_XT_MATCH_HASHLIMIT=y to CONFIG_NETFILTER_XT_MATCH_HASHLIMIT=m. In short I installed that module separately rather within the kernel itself. Now it doesn't say,
iptables v1.6.2: Couldn't load match `hashlimit':No such file or directory
Instead I get this,
root@OpenWrt:~# iptables -t mangle -A POSTROUTING -p udp -m hashlimit --hashlimi
t-name udp_high_prio --hashlimit-above 115/sec --hashlimit-burst 50 --hashlimit-
mode srcip,srcport,dstip,dstport -j CONNMARK --set-mark 0x55 -m comment --commen
t "connmark for udp"
iptables: Result not representable.
Also, what is this file /etc/iproute2/rt_dsfield for? I checked on wireshark & DSCP packets are working without this.
i think it's ok.
you can check by watching this rule stats!
this have the hex value for each of DSCP class, i guess it's not needed with newer versions of iptables
1 Like