My thought is that it should be included in PR #22533, so that it would consistently enable offload, whether you have VLAN, PPPoE, or neither, which I imagine would be the expected behavior of this patch.
This patch is intended to replace bridger, but in any case those settings don't affect bridger as bridger is not dependent on kmod-br-netfilter.
And if you don't want to offload anything, you can always disable it in the firewall settings, which is the default.
1 Like
Are you coming from an existing build of OpenWrt? If so, did you notice an error being logged like the one below?
ubidetach: error!: cannot detach "/dev/mtd2"
error 16 (Resource busy)
I don't believe this generally results in the recovery volume being written, as it is on mtd2, but could be related to the issue documented here: https://github.com/hurrian/w1700k-ubi-installer/issues/3
1 Like
The PR is to add support but not necessary to enable it. I am following the logic from mtk sdk.
I suppose your approach is to add by default and disable if you donāt need. I am the exact opposite and I donāt enable unless I need it and knows exactly what it does.
I get you. I'm just saying enabling/disabling offload should be via the usual place (although the firewall settings was never the most intuitive locale, but that was a design decision made many moons ago)...
...and not via some extremely obscure command line setting.
2 Likes
Understand and agree. Personally I have my own rants about fw4. If you follow fw4 you will see multi-year frustrations. Which is also why I still use a build without offload for production. But thatās for another day when I feel grumpy.
Edit:
Not trying to pour cold water. I have very little expectation of the nft_flow_offload for bridging PR getting merged. Hope to be pleasantly surprised thou.
Yes. i do. it looks similar. is there any solution?
You can upgrade to a 6.18 series build with no issue on the current chainloader.
You will only need to rerun the installer if you want to get the new chainloader features (namely the ability to use reset button to trigger recovery).
4 Likes
Just to confirm. the 6.18 chainloader on your repo supports this now?
Not yet, the final/non-prerelease version will have it.
2 Likes
Is your 6.18 airoha PR ready for testing or still a wip? Do you have a working branch for w1700k that I can clone and test? Nothing much happening on 6.12 front and has been stable for past few weeks for me.
It's ready, the PR branch can be built and flashed. Just select the testing kernel in menuconfig.
5 Likes
I'm just saying enabling/disabling offload should be via the usual place (although the firewall settings was never the most intuitive locale, but that was a design decision made many moons ago)...
You could add the option something like...
Sorry rchen14b I've been playing with your awesome app 
5 Likes
@OpenWRT-fanboy I don't know if the VLAN problem is really caused by offloading
I can observe that I have the problem even with software offloading, or offloading disabled.
No difference either with net.bridge.bridge-nf-filter-vlan-tagged = 1 or 0.
But, if I put the tv player on a channel (nothing is displayed, black screen), and I restart firewall, then the tv stream is displayed !
If I change channel, black screen again.
So I guess the firewall is blocking something, but I thought that it shouldn't filter the packets as my VLAN wan.100/br-lan.100 devices and tv-bridge aren't in fw zones (lan or wan).
I want to integrate that. Please share your mod.
When you switch between 1 and 0 net.bridge.bridge-nf-filter-vlan-tagged = 1 or 0 is that with the echo command or changing /etc/sysctl.conf?
I tried both.
But here I really think there's something with the firewall.
When I stop the firewall, VLAN100 bridge between WAN and LAN is working, because TV works.
If I stop the bridge or restart firewall, TV stream stops.
Ah okay. I you change sysctl.conf, remember to run: sysctl -p to apply changes after save.
I remember I struggled to stream TV because of that proxy stuff. Multicast and so on... this is ages ago, but hope you figure it out 
What is weird is that the same config worked in previous builds where there was bridger.
Now bridger is gone, it doesn't work, unless I stop firewall.
But I can't see why it acts like that, firewall should not block it.
Edit : Here it is !!
If I put the bridge interface in the lan firewall zone, it works !
2 Likes
I just built a version that removes the @tesf23 offload patch and restores bridger so you can do some A/B testing and figure this out (available on GASU).
But now maybe that's not necessary.
1 Like
Thanks, but now I don't think it is necessary 
With @hwti's help, we seen in that commit : https://github.com/OpenWRT-fanboy/OpenW1700k/commit/fab48075cb89da867ae58e44c39aa6b57693012f :
Set bridge-nf-call-iptables=1 and bridge-nf-call-ip6tables=1 via
sysctl at boot. Without these, bridged packets bypass netfilter
entirely and never reach the flowtable.
So with the new method (instead of bridger), all bridges packets are sent to netfilter.
Then, my VLAN bridge between LAN and WAN is filtered by firewall, and without a specfic zone, packets are rejected by default.
It's a very specific side effect of moving from bridger to netfilter for offloading.
Thanks for your support as always.
4 Likes