In @Lynx's case, if wan is in the flowtable, software flow offloading steals the packet from there (even though it has a VLAN header, that's the whole point). However, the exact point where it is stolen is a bit tricky:
It is after the point where qdiscs on wan could see the packet (and ignore it)
It is before the point where the kernel diverts it to wan.1 without the VLAN tag
As the packet is stolen in such a way that it never hits the wan.1 interface (although the equivalent processing is still done elsewhere), obviously, no qdisc attached to that interface will see it.
If the flowtable contained only wan.1 and not wan, then the qdisc on wan.1 would have had a chance to see the packets:
First, the qdisc on wan sees the packet and ignores it
Second, the kernel decides not to use flow offloading so far, as wan is not in the flowtable
Third (which is the step short-circuited and thus not executed in your current setup), the packet is diverted to wan.1 without the VLAN tag
Fourth, the qdisc on wan.1 takes a note of the packet
Fifth, the kernel checks for flow offloading again and uses it.
The same logic applies when both wan and pppoe-wan are in the flowtable, but with a twist that there was a kernel issue with the incorrect MTU being applied, or flow offloading not working due to the IP headers being not in the place where the kernel expected them.
To make the obvious clear, I am still on iptables and have looked only little to nftables, but will switch over hopefully this year, so my interest in nftables increased by a lot
I meant that flow offloading worked (as in: improved performance, regardless of any qdiscs) only if pppoe-wan was in the table and wan wasn't, however, this is not how the firewall is set up by default in 23.05.5, and it is not how the firewall is set up even in snapshots if both pppoe-wan (as a real WAN) and wan (to access the modem UI) interfaces are used.
Is there a way to have qdiscs operate only on packets with specific vlan tag? Or do you always just need to setup appropriate devices e.g. with routing or IFBs?
Yes - attach them to wan.1, not wan, and make sure that the flowtable does not contain wan (which is impossible without upgrading fw4 to a version from the snapshot).
Alternatively, you can try the u32 classifier to peek at packets in arbitrary places, but it's at the very least ugly and needs to be very carefully written.
P.S. what speeds are we talking about? Even with a WireGuard VPN and SQM together, on Linksys E8450, you don't need flow offloading until you hit 150 Mbps.
Ah, I rather meant a qdisc on wan that applies cake only to specific packets identified by vlan. I see how wan.1 would work now by ensuring flowtable does not include wan (and it can still include wan.1 it seems providing I understood your explanation above correctly).
Yes it's just academic in my case as I never see bandwidths greater than 100Mbit/s.
By the way this all came about because I wanted to leverage my outdoor NR7101's WiFi antennas, requiring me to setup a wan.2 and wan.3 for conveying WiFi traffic together with the wan.1 actual wan traffic all over the same cable.
This worked but broke cake, and now I understand why.
I suppose then this wouldnât have worked in my case and I ought rather to have wan.1, wan.2 and wan.3 in the table rather than wan. Shouldnât this be user configurable in config and LuCi?
