> > I thought we have established that checking device MTU (m*T*u) > > at ingress makes a very limited amount of sense, no? > > > > Shooting from the hip here, but won't something like: > > > > if (!skb->dev || skb->tc_at_ingress) > > return SKB_MAX_ALLOC; > > return skb->dev->mtu + skb->dev->hard_header_len; > > > > Solve your problem? > > I believe that probably does indeed solve the ingress case of tc > ingress hook on cellular redirecting to wifi. > > However, there's 2 possible uplinks - cellular (rawip, L3), and wifi > (ethernet, L2). > Thus, there's actually 4 things I'm trying to support: > > - ipv6 ingress on cellular uplink (L3/rawip), translate to ipv4, > forward to wifi/ethernet <- need to add ethernet header > > - ipv6 ingress on wifi uplink (L2/ether), translate to ipv4, forward > to wifi/ethernet <- trivial, no packet size change > > - ipv4 egressing through tun (L3), translate to ipv6, forward to > cellular uplink <- trivial, no packet size change > > - ipv4 egressing through tun (L3), translate to ipv6, forward to wifi > uplink <- need to add ethernet header [*] > > I think your approach doesn't solve the reverse path (* up above): > > ie. ipv4 packets hitting a tun device (owned by a clat daemon doing > ipv4<->ipv6 translation in userspace), being stolen by a tc egress > ebpf hook, mutated to ipv6 by ebpf and bpf_redirect'ed to egress > through a wifi ipv6-only uplink. > > Though arguably in this case I could probably simply increase the tun > device mtu by another 14, while keeping ipv4 route mtus low... > (tun mtu already has to be 28 bytes lower then wifi mtu to allow > replacement of ipv4 with ipv6 header (20 bytes extra), with possibly > an ipv6 frag header (8 more bytes)) > > Any further thoughts? Thinking about this some more, that seems to solve the immediate need (case 1 above), and I can work around case 4 with tun mtu bumps. And maybe the real correct fix would be to simply pass in the desired path mtu to these 3 functions via 16-bits of the flags argument.
