UDP sockets bound to ANY send answers with wrong src ip address

From: Denis Vlasenko
Date: Wed Jun 09 2004 - 06:34:28 EST


I observe that UDP sockets listening on ANY
send response packets with ip addr derived from
ip address of interface which is used to send 'em
instead of using dst ip address of client's packet.

I was bitten by this with DNS and NTP.

This is a test setup:

{net 172.16/16}----- 172.16.22.2 [multihomed] 195.66.192.167 ----....

This is a UDP server on multihomed box:
# echo test | nc -vvvnu -l -p 222
listening on [any] 222 ...
connect to [172.16.22.2] from (UNKNOWN) [172.16.42.177] 333
ping
sent 5, rcvd 5 : Connection refused
#

This is client on 172.16.42.177:
# echo ping | nc -vvvnu -p 333 195.66.192.167 222
(UNKNOWN) [195.66.192.167] 222 (?) open

it waits forever, never getting 'test' string from server.

This is a tcpdump of this event:
13:58:00.555207 172.16.42.177.333 > 195.66.192.167.222: udp 5 (DF)
13:58:00.559849 172.16.22.2.222 > 172.16.42.177.333: udp 5 (DF)
^^^^^^^^^^^
13:58:00.560457 172.16.42.177 > 172.16.22.2: icmp: 172.16.42.177 udp port 333 unreachable [tos 0xc0]

This is why 172.16.42.177 thinks that port 333 is unreachable:
# lsof -nP | grep 333
ntpd 418 root mem REG 3,4 133316 68184 /.share/usr/lib/all-lib/libreadline.so.3.0
most 7559 root txt REG 3,4 46828 24333 /.share/usr/app/most-4.9.2/bin/most
nc 15085 root 3u IPv4 29381 UDP 172.16.42.177:333->195.66.192.167:222
# ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

kernel does not think that 172.16.22.2.222 > 172.16.42.177.333 packet
belong to this socket, and it is right imo.

Test works ok if I remove -u from both netcats (i.e. TCP works).

client:
# uname -a
Linux firebird 2.6.6-rc1-bk1 #1 Wed May 26 11:03:11 EEST 2004 i686 unknown

server:
# uname -a
Linux oldie 2.4.22-rc2_QoS #1 Tue Nov 18 15:55:00 GMT-2 2003 i586 unknown
root@oldie:/.share/home/vda#

I saw this behavior on 2.6 based machines as well.
--
vda
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html