From: Eric Dumazet <eric.dumazet@gmail.com>
To: Andrew Cann <shum@canndrew.org>, netdev@vger.kernel.org
Subject: Re: UDP packets arriving on wrong sockets
Date: Thu, 2 Aug 2018 06:20:12 -0700 [thread overview]
Message-ID: <be3908e6-252f-eb10-a7ac-e2559e98dda6@gmail.com> (raw)
In-Reply-To: <20180802090505.GA29624@canndrew.org>
On 08/02/2018 02:05 AM, Andrew Cann wrote:
> Hi,
>
> I posted this on stackoverflow yesterday but I'm reposting it here since it got
> no response. Original post: https://stackoverflow.com/questions/51630337/udp-packets-arriving-on-wrong-sockets-on-linux
>
> I have two UDP sockets bound to the same address and connected to addresses A
> and B. I have two more UDP sockets bound to A and B and not connected.
>
> This is what my /proc/net/udp looks like (trimmed for readability):
>
> sl local_address rem_address
> 3937: 0100007F:DD9C 0300007F:9910
> 3937: 0100007F:DD9C 0200007F:907D
> 16962: 0200007F:907D 00000000:0000
> 19157: 0300007F:9910 00000000:0000
>
> According to connect(2): "If the socket sockfd is of type SOCK_DGRAM, then addr
> is the address to which datagrams are sent by default, *and the only address
> from which datagrams are received*."
>
> For some reason, my connected sockets are receiving packets that were destined
> for each other. eg: The UDP socket connected to A sends a message to A, A then
> sends a reply back. The UDP socket connected to B sends a message to B, B then
> sends a reply back. But the reply from A arrives at the socket connected to B
> and the reply from B arrives at the socket connected to A.
>
> Why on earth would this be happening? Note that it happens randomly - sometimes
> the replies arrive at the correct sockets and sometimes they don't. Is there
> any way to prevent this or any situation under which connect() is supposed to
> not work?
>
> Any help explaining this would be hugely appreciated :)
Hi Andrew
Well, you should first give much more details, as there are thousands of different UDP stacks out there.
Documentation/admin-guide/reporting-bugs.rst
...
[4.1.] Kernel version (from /proc/version):
...
Ideally you could give us a C reproducer, so that we can run it ourselves and fix the kernel bug if there is one.
This C reproducer could be part of an official patch, adding a test in tools/testing/selftests/net
Thanks !
next prev parent reply other threads:[~2018-08-02 15:11 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-02 9:05 UDP packets arriving on wrong sockets Andrew Cann
2018-08-02 13:20 ` Eric Dumazet [this message]
2018-08-02 13:35 ` Eric Dumazet
2018-08-02 15:21 ` Willem de Bruijn
2018-08-02 15:28 ` Eric Dumazet
2018-08-03 4:19 ` Andrew Cann
2018-08-03 14:20 ` Willem de Bruijn
2018-08-03 15:20 ` Andrew Cann
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=be3908e6-252f-eb10-a7ac-e2559e98dda6@gmail.com \
--to=eric.dumazet@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=shum@canndrew.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.