lkml.org 
[lkml]   [2020]   [May]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH v2] net: bpf: permit redirect from L3 to L2 devices at near max mtu
    > > 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.

    \
     
     \ /
      Last update: 2020-05-07 04:33    [W:2.755 / U:0.036 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site