[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <be3908e6-252f-eb10-a7ac-e2559e98dda6@gmail.com>
Date: Thu, 2 Aug 2018 06:20:12 -0700
From: Eric Dumazet <eric.dumazet@...il.com>
To: Andrew Cann <shum@...ndrew.org>, netdev@...r.kernel.org
Subject: Re: UDP packets arriving on wrong sockets
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 !
Powered by blists - more mailing lists