On Wed, Jun 29, 2016, at 20:47, Shmulik Ladkani wrote: > ip_skb_dst_mtu uses skb->sk, assuming it is an AF_INET socket (e.g. it > calls ip_sk_use_pmtu which casts sk as an inet_sk). > > However, in the case of UDP tunneling, the skb->sk is not necessarily an > inet socket (could be AF_PACKET socket, or AF_UNSPEC if arriving from > tun/tap). > > OTOH, the sk passed as an argument throughout IP stack's output path is > the one which is of PMTU interest: > - In case of local sockets, sk is same as skb->sk; > - In case of a udp tunnel, sk is the tunneling socket. > > Fix, by passing ip_finish_output's sk to ip_skb_dst_mtu. > This augments 7026b1ddb6 'netfilter: Pass socket pointer down through > okfn().' > > Signed-off-by: Shmulik Ladkani <shmulik.ladk...@gmail.com> > --- > > Discovered while debugging other issue in adjacent code area. > > My setup seems to be handling this well; However I'd appreciate a > Tested-by or Reviewed-by as one can only cover relatively few of the > possible code flows leading to ip_skb_dst_mtu.
Well spotted. It all looks good, the socket's pmtudisc field is initialized accordingly and I suspect people want to have vxlan to use the path mtu when transmitting packets, even during forwarding. Maybe this can be tweaked with an additional patch, if people want to change this behavior. But as your patch doesn't change any of this, Reviewed-by: Hannes Frederic Sowa <han...@stressinduktion.org> Thanks!
