The details matter though. A company running a separate wifi SSID exclusively for VOIP handsets would see a different situation.
Can I redirect OpenWrt->wan to ifb-ul and also redirect wan->OpenWrt to ifb-dl to these IFBs:
This hinges on how IFBs work. @dlakelan thinks maybe redirecting OpenWrt->wan from wan egress to ifb-ul might result in a loop in which packet is directed to ifb-ul and then exits back on wan but when I tested that it actually seemed to work? Although I hadn't managed to test download yet.
I think the answer is yes, but I'm not 100% sure.
anecdote: Last week: replaced a 15Kbyte gbit ethernet bfifo running against a wireless ac ap, with fq_codel native. Performance doubled.
This is 100us at gigabit so it doesn't surprise me. If it were 150kB or even 300kB what happens?
not gonna bother to care. fq_codel everywhere solves nearly everything, and cake solves the rest. 
1 Like
Wifi traffic should go through his cake shaper so the wan interface should never see such 4 M lumps arriving instantaneously...
Even there fq is helpful, think about a device that pulls its updates over WiFi and introduces large "bubbles" in the FIFO...
Or an unfair queue... Such as WMM. If the updates are in bulk tin while voice packets in voice queue.
1 Like
Except I would first want to see data whether VoIP in AC_VO actually results in better performance for VoIP and the other traffic, over VoIP on AC_VI or even everything in AC_BE.
My admittedly limited research into the experiments under-pinning the WMM/DSCP recommendations di not leave me with the impression that all of this was based on hard empirical data...
E.g. when rfc8325 recommended to change the mapping of EF effectively from AC_VI to AC_VO there is exactly zero references to experiments that show if/how this affects the QoE of the voice and of all other traffic on that AP. I cynically start to think the justification is not much deeper than:
since AC_VO is short for access class voice, and EF markings are used by voice over IP applications, EF should map into AC_VO. While what I would have liked to see is an empiric study showing how putting VoIP in AC_VO improves voice performance over AC_VI and what side-effect this change has on latency, jitter, and throughput of flows in the other ACs.
I am not arguing against "unfair" queues (I realize that there is some need for what I call targeted unfairness) I am arguing against untargeted unfairness 
2 Likes
Agreed when you look into a lot of things it seems that the justification is often highly problematic. For example I am currently doing a data analysis related to poverty and if you'd like to see something really dumb in terms of justification take a look at how the US government defines poverty.
1 Like
Wait! What?! "does not include capital gains or noncash benefits "
Can anyone advise how to use nftables to capture only packets originating from OpenWrt and passed through wan?
firewall4 uses the route output hook.
chain mangle_output {
type route hook output priority mangle; policy accept;
}
1 Like
Thanks.
If I want to fwmark br-lan/br-guest to wan for pickup by tc ingress filter on fwmark?
So far I have:
table bridge cake-dual-ifb-bridge {
chain mark-lan-wan {
type filter hook input priority 0
ip daddr != { 192.168.1.1/32, 255.255.255.255/32, 224.0.0.0/4 } mark set 1
}
}
Is there a simpler way?
I don’t understand this question.
I'm trying to set fwmark 1 on br-lan and br-guest traffic destined for wan very early on. I believe that I can do this using the bridge family and 'input' hook in the bridge family. But I don't know the best way to ensure I am only marking on bridge ingress destined for wan.
What I have above more or less works, but I'm not sure it's optimum.
This traffic gets captured by tc (after having been marked by nftables) using (for br-lan):
# capture br-lan (ingress) -> wan
tc filter add dev br-lan parent ffff: protocol ip handle 1 fw flowid 1:1 action mirred egress redirect dev ifb-ul
That is, I use tc to filter on mark 1, and I just need to set mark 1 using nftables on br-lan/br-guest ingress destined for wan. I discovered that the ingress hook in the bridge family is sufficiently early on to do this, but I just don't know how to best mark only the wan destined ingress there.
@dlakelan is conntrack set in time for tc ingress on wan to pick it up with e.g.:
# capture wan (ingress) -> OpenWrt and restore DSCPs from conntracks
# filter on conntrack bit 128 set
tc filter add dev wan parent ffff: protocol ip flower ct_mark 128/128 action ctinfo dscp 63 128 action mirred egress redirect dev ifb-dl
I am setting using:
chain capture-OpenWrt-wan {
type filter hook output priority 0
oifname wan mark !=0x2 mark set 3 goto process-upload
}
chain process-upload {
# store DSCPs in conntracks
meta nfproto ipv4 ct mark set (@nh,8,8 & 252) >> 2
meta nfproto ipv6 ct mark set (@nh,0,16 & 4032) >> 6
ct mark set ct mark or 128
}
Read @ldir's original commit for act_ctinfo.
There is a cpmark action to retrieve the connmark to skb mark on ingress.
Thanks @dave14305.
So is the point that.
# capture wan (ingress) -> OpenWrt and restore DSCPs from conntracks
# filter on conntrack bit 128 set
tc filter add dev wan parent ffff: protocol ip flower ct_mark 128/128 action ctinfo dscp 63 128 action mirred egress redirect dev ifb-dl
reads from skb mark on the packet not from the conntrack mark?
I tried this:
tc filter add dev wan parent ffff: matchall action connmark continue
tc filter add dev wan parent ffff: protocol ip flower ct_mark 128/128 action ctinfo dscp 63 128 action mirred egress redirect dev ifb-dl
But don't think it's working.
I can no longer follow all your different scenarios and ideas. All I can suggest is that you closely observe the mark= field in /proc/net/nf_conntrack to see if your marks are being stored. Then do some nftables logging to see if they are still there after being restored in the other direction.