From: David Ahern <dsahern@gmail.com>
To: Preethi Ramachandra <preethir@juniper.net>
Cc: Reji Thomas <rejithomas@juniper.net>,
Yogesh Ankolekar <ayogesh@juniper.net>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: PMTU discovery broken in Linux for UDP/raw application if the socket is not bound to a device
Date: Tue, 9 Oct 2018 10:23:37 -0600 [thread overview]
Message-ID: <6ebc8ad8-7e08-7d94-73d8-3dd9feb8b0f3@gmail.com> (raw)
In-Reply-To: <4138E416-D846-47B2-AA9F-593313041E6F@juniper.net>
[ adding netdev so others know ]
On 10/9/18 3:38 AM, Preethi Ramachandra wrote:
> Hi David,
>
> I tested your fix, Linux is updating PMTU successfully.
ok, I'll send a formal patch
>
> Thanks,
> Preethi
>
> On 10/7/18, 8:59 AM, "David Ahern" <dsahern@gmail.com> wrote:
>
> The correct mailing list is netdev@vger.kernel.org (added)
>
> non-text emails will be rejected.
>
>
> On 10/3/18 10:15 PM, Preethi Ramachandra wrote:
> > Hi,
> >
> >
> >
> > While testing the PMTU discovery for UDP/raw applications, Linux is not
> > doing PMTU discovery if the UDP server socket is not bound to a device.
> > In the scenario we are testing there could be multiple VRF devices
> > created and an application like UDP/RAW can use a common socket for all
> > vrf devices. While sending packet IP_PKTINFO socket option can be used
> > to specify the vrf interface through which packet will be sent out. In
> > this case, when packet too big icmp6 error message comes back to Linux
> > on a vrf device, a route lookup is done on default routing-table(0) for
> > src/dst address which case, the route will not be found and packet is
> > dropped. If the route lookup happened with proper VRF device (packet’s
> > incoming index), the route lookup succeeds, PMTU discovery is successful.
> >
> >
> >
> > This might need a fix, please take a look.
> >
> >
> >
> > *Linux version *
> >
> >
> >
> > Linux 4.8.24
> >
> >
> >
> > *Code flow *
> >
> >
> >
> > Linux code where it expects socket’s bound device in order for PMTU
> > discovery to happen.
> >
> > *void ip6_sk_update_pmtu*(struct sk_buff *skb, struct sock *sk, __be32 mtu)
> >
> > {
> >
> > struct dst_entry *dst;
> >
> >
> >
> > ip6_update_pmtu(skb, sock_net(sk), mtu,
> >
> >
> > sk->sk_bound_dev_if, sk->sk_mark, sk->sk_uid);*<<<<< This is the point
> > where it expects socket’s sk_bound_dev_if to be set. In our testing this
> > is actually 0, since the socket is not really bound to a vrf device.*
>
> Try this based on top of tree for 4.19-next (whitespace damaged on paste
> so you'll need to manually apply and handle differences with 4.8):
>
> diff --git a/net/ipv6/route.c b/net/ipv6/route.c
> index 6c1d817151ca..50b95b48b911 100644
> --- a/net/ipv6/route.c
> +++ b/net/ipv6/route.c
> @@ -2360,10 +2360,13 @@ EXPORT_SYMBOL_GPL(ip6_update_pmtu);
>
> void ip6_sk_update_pmtu(struct sk_buff *skb, struct sock *sk, __be32 mtu)
> {
> + int oif = sk->sk_bound_dev_if;
> struct dst_entry *dst;
>
> - ip6_update_pmtu(skb, sock_net(sk), mtu,
> - sk->sk_bound_dev_if, sk->sk_mark, sk->sk_uid);
> + if (!oif && skb->dev)
> + oif = l3mdev_master_ifindex(skb->dev);
> +
> + ip6_update_pmtu(skb, sock_net(sk), mtu, oif, sk->sk_mark,
> sk->sk_uid);
>
> dst = __sk_dst_get(sk);
> if (!dst || !dst->obsolete ||
>
>
>
>
prev parent reply other threads:[~2018-10-09 23:41 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <811A4496-322E-443D-9B07-46E6BC406C38@juniper.net>
[not found] ` <E27EC374-F7B1-4DD2-960A-6A63818DDBD7@juniper.net>
2018-10-07 3:28 ` PMTU discovery broken in Linux for UDP/raw application if the socket is not bound to a device David Ahern
[not found] ` <4138E416-D846-47B2-AA9F-593313041E6F@juniper.net>
2018-10-09 16:23 ` David Ahern [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6ebc8ad8-7e08-7d94-73d8-3dd9feb8b0f3@gmail.com \
--to=dsahern@gmail.com \
--cc=ayogesh@juniper.net \
--cc=netdev@vger.kernel.org \
--cc=preethir@juniper.net \
--cc=rejithomas@juniper.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).