NFtables and QoS in 2021

[Lynx]

So I understand that as @tohojo stated:

@tohojo

No, the problem is that a wireguard interface is layer 3 only, so the packets are missing an Ethernet header. Which means that just redirecting won't work. You could do the redirecting with a BPF program and have that add an Ethernet header first (and remove it again later), but that becomes messy quickly...

there are no headers, and so in forwarding the packets to an IFB you end up with something like:

11:02:12.674405 40:00:6c:06:86:f4 (oui Unknown) > 45:00:00:57:d1:22 (oui Unknown), ethertype Unknown (0x3470), length 87:
        0x0000:  7813 0a05 0002 01bb ce0b 96af 9437 464f  x............7FO
        0x0010:  8843 5018 07fb 2b58 0000 1703 0300 2a00  .CP...+X......*.
        0x0020:  0000 0000 0000 b390 2546 fbc5 aeef 7af5  ........%F....z.
        0x0030:  5c6d 549d bf3a da05 825c 5a16 8dd9 0905  \mT..:...\Z.....
        0x0040:  6a67 24dd 40ee 822a aa                   jg$.@..*.

and I understand that this means that CAKE does not see the proper flow information?

@dlakelan

Does this actually matter for NF tables packet processing

Perhaps DSCP marks could be applied in nftables using a VPN ingress hook that is preserved outside, or presumably more naturally by using a postrouting hook, but this doesn't help in terms of getting the single interface combining mixture of flows from WAN/VPN needed for CAKE, right?

In 'nftables' 'fwd to' only works in the context of netdev, and forwarding from the WireGuard interface apparently does not work given the lack of the headers. So ingress on the vpn interface won't work, and although 'egress' from 'br-lan'/'br-guest' will work, that's not supported yet.