hi jimmy I don't know if qosify is compatible with sfo and hwo but I seem to have heard that with firewall 4 we can activate it at the same time as a qos such as sqm or qosify , someone can confirm because I'm not 100% sure
before with iptables sqm was not compatible with hardware offload
So, I was playing with it yesterday and I even bricked my router for a minute (yellow light -- had to reflash through tftp server, lol). Nevertheless, I tested both versions (0.6.1 and 0.6.2) with SQM and qosify (not at the same time, of course), and SW and HW flow offloading.
What I found was that both shapers work with SW flow offloading. But, the big difference, only with version 0.6.1 (I believe firewall3) the HW flow offloading works (albeit disabling traffic shapers), while with version 0.6.2 (I believe firewall4) HW flow offloading just made my connection unusable (no internet connection). The reason I think SW flow offloading works with sqm and qosify is because without it enabled my connection speed maxes out at around 350-400 mbps, but with it enabled it reaches 500mbps easily, and my bufferbloat still look under control (testing with the bufferbloat test from waveform.com and fast.com).
It wasn't a special config (wireless on channel 100 / 160Mhz, Intel ax210 client and for qosify I only edited the bandwidth) but it was a special build with wireless-ethernet-dispatch patches from Felix's tree which offloads to hardware the "downloading" part, i.e. from internet to the client. But after a day or so the router crashed and I switched to normal master builds. I tried on several occasions new builds with wed patches but unfortunately I could not replicate again the "acceleration" part. I am using one right now (confirmed by the "mt7915e 0000:01:00.0: attaching wed device 0" message) and I have the hw offloading switch checked but I think it isn't working because there is no CPU usage improvement: I am now using channel 36/80Mhz and for 700Mb/s download I have 40% CPU usage with half of it = softirq. During the waveform bufferbloat test the CPU goes up to 60%.
Also the router seems stable, no crashes, which somehow confirms that the hw offloading is not engaged.
General question for folks compiling their own firmware for this target, do you get an ocasional failure to build package/boot/arm-trusted-firmware-mediatek which can be circumvented simply by running make again?
make -C feeds/luci/themes/luci-theme-bootstrap compile
make -C feeds/luci/protocols/luci-proto-ipv6 compile
ERROR: package/boot/arm-trusted-firmware-mediatek failed to build (build variant: mt7622-snand-1ddr).
make -r world: build failed. Please re-run make with -j1 V=s or V=sc for a higher verbosity level to see what's going on
make: *** [/scratch/union/include/toplevel.mk:230: world] Error 1
Again, simply running make at this point finishes the build and the resulting image/packages are fine. Thinking might be some race condition?
I think that stabilizing the new nftables firewall4 is probably the largest factor affecting the timeframe. Thanks to the wider usage (real-life testing) in the last few weeks, some bugs have surfaced and have been fixed.
I haven't seen that ever. I build inside a debian VM with half my 'cores' assigned to it (6-core machine, 12 threads with hyperthreading). Might be relevant since such failures are often caused by build race conditions
Ok the weirdest thing happens since a recent update of my RT3200, which I really think is a broader OpenWRT problem.
Behind my rotuer I have a webserver, a LetsEncrypt certificate and a nice port forward for port 80 and 443 from my external IP towards that machine (plus IPv6 firewall rules). Previously there was no issue accessing that server from inside the network through the external IP, or rather, a domain name that resolves to the external IP (and to the correct IPv6 address, which doesn't require NAT).
Just now I used my browser on a different machine to connect to that server, and initially all went fine. Then as I tried to post a web form in a mediawiki instance on the server (which I had also used multiple times in the minutes before!) I suddenly got a Firefox warning that there's a certificate error. Upon inspection of the certificate it turns out to be an OpenWRT self-signed certificate! Very odd behaviour, because I haven't changed anything on the router in between successful form posts and this failed certificate check. In other words, routing seems to randomly differ between the server I want it to access and... maybe the OpenWRT web interface? It certainly seems that way, because if I tell FF to ignore the cert error I get "Rejected request from RFC1918 IP to public server address".
I just performed another upgrade, fingers crossed that the firewall updates from two days ago make a difference.
Did you manage to get it working? Tried with a fresh snapshot install but there are no active redirects on the luci page but the system log says that it's creating the rules, not sure why is not working
No, I switched back to firewall3 (not using snapshots, but building my own versions). Maybe the developer doesn't believe there is a problem, because it works for him, you can follow this conversation: https://github.com/openwrt/packages/pull/17094 with Daniel and others saying (like us) that rules don't have effect but Stijn saying it works for him...