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 !
