All of lore.kernel.org
 help / color / mirror / Atom feed
From: Saikrishna Arcot <sarcot@microsoft.com>
To: "netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Change in behavior for bound vs unbound sockets
Date: Mon, 30 Aug 2021 23:47:53 +0000	[thread overview]
Message-ID: <BL0PR2101MB13167E456C5E839426BCDBE6D9CB9@BL0PR2101MB1316.namprd21.prod.outlook.com> (raw)

Hi all,

When upgrading from 4.19.152 to 5.10.40, I noticed a change in behavior in how incoming UDP packets are assigned to sockets that are bound to an interface and a socket that is not bound to any interface. This affects the dhcrelay program in isc-dhcp, when it is compiled to use regular UDP sockets and not raw sockets.

For each interface it finds on the system (or is passed in via command-line), dhcrelay opens a UDP socket listening on port 67 and bound to that interface. Then, at the end, it opens a UDP socket also listening on port 67, but not bound to any interface (this socket is used for sending, mainly). It expects that for packets that arrived on an interface for which a bound socket is opened, it will arrive on that bound socket. This was true for 4.19.152, but on 5.10.40, packets arrive on the unbound socket only, and never on the bound socket. dhcrelay discards any packets that it sees on the unbound socket. Because of this, this application breaks.

I made a test application that creates two UDP sockets, binds one of them to the loopback interface, and has them both listen on 0.0.0.0 with some random port. Then, it waits for a message on those two sockets, and prints out which socket it received a message on. With another application (such as nc) sending some UDP message, I can see that on 4.19.152, the test application gets the message on the bound socket consistently, whereas on 5.10.40, it gets the message on the unbound socket consistently. I have a dev machine running 5.4.0, and it gets the message on the unbound socket consistently as well.

I traced it to one commit (6da5b0f027a8 "net: ensure unbound datagram socket to be chosen when not in a VRF") that makes sure that when not in a VRF, the unbound socket is chosen over the bound socket, if both are available. If I revert this commit and two other commits that made changes on top of this, I can see that packets get sent to the bound socket instead. There's similar commits made for TCP and raw sockets as well, as part of that patch series.

Is the intention of those commits also meant to affect sockets that are bound to just regular interfaces (and not only VRFs)? If so, since this change breaks a userspace application, is it possible to add a config that reverts to the old behavior, where bound sockets are preferred over unbound sockets?

--
Saikrishna Arcot


             reply	other threads:[~2021-08-30 23:47 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-30 23:47 Saikrishna Arcot [this message]
2021-08-31 10:12 ` Change in behavior for bound vs unbound sockets Paul Menzel
2021-09-01  2:29   ` David Ahern
2021-09-02  0:16     ` [EXTERNAL] " Saikrishna Arcot
2021-09-02  3:41       ` David Ahern

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=BL0PR2101MB13167E456C5E839426BCDBE6D9CB9@BL0PR2101MB1316.namprd21.prod.outlook.com \
    --to=sarcot@microsoft.com \
    --cc=netdev@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.