Re: strange behavior when the client bind its UDP socket to a local address
- From: Pascal Hambourg <boite-a-spam@xxxxxxxxxxxxxxx>
- Date: Tue, 20 Jan 2009 01:38:12 +0100
Hello,
David Schwartz a écrit :
On Jan 16, 5:04 am, Christophe Lohr <christophe.l...@xxxxxxxxxxxxxxxx>
wrote:
Server part:
$ nc -u -l -p 5555
Client part:
$ nc -u -s 192.168.75.62 localhost 5555
Sniffing lo:
# tshark -i lo
192.168.75.62 -> 127.0.0.1 UDP Source port: 39293 Destination
port: 5555
192.168.75.62 -> 192.168.75.62 UDP Source port: 5555 Destination
port: 39293
192.168.75.62 -> 192.168.75.62 ICMP Destination unreachable (Port
unreachable)
So, why is the second packet from 192.168.75.62 to 192.168.75.62 ???
Probably because the server used the default source address selected by the stack instead of using the destination address in the received packet.
Because 192.168.75.62 is "closer" to 192.168.75.62 than 127.0.0.1 is.
Normally, the networking stack will try to pick the closest source
interface address it can.
From my observations of the behaviour of the Linux IPv4 stack, I did not see any evidence that the default source adresse selection is based on "closeness" to the destination address. AFAICS, the default source address selection works as follows :
- If the destination is local (on the host), then use the same address as source. This is what is happening here.
- If the route covering the destination specifies an explicit source address, use that source address. This is usually what happens for directly attached subnets.
- Otherwise, use the primary address of the output interface specified in the route covering the destination, if it exists.
- Otherwise, when the output interface has no address, use the primary address of the first non-loopback interface.
(and not from 127.0.0.1 to 192.168.75.62)
Why would it deliberately pick a worse address?
Because the client sent a datagram to 127.0.0.1 and expects datagrams from the same address, not 192.168.75.62.
Although UDP is connectionless, it is rather common that bidirectional UDP communications use source and destination adresses in the same way as TCP does. At least it is common enough so that this is what the UDP connection tracking in netfilter expects.
Now a last comment. As a client, when nc sends a UDP datagram to address A it expects to receive datagrams from the same address A. However as a server, when nc receives a UDP datagram on address A it may send datagrams from a different address. This looks like a bug to me.
.
- Follow-Ups:
- Re: strange behavior when the client bind its UDP socket to a local address
- From: David Schwartz
- Re: strange behavior when the client bind its UDP socket to a local address
- From: Christophe Lohr
- Re: strange behavior when the client bind its UDP socket to a local address
- References:
- strange behavior when the client bind its UDP socket to a local address
- From: Christophe Lohr
- Re: strange behavior when the client bind its UDP socket to a local address
- From: David Schwartz
- strange behavior when the client bind its UDP socket to a local address
- Prev by Date: Make Money Online
- Next by Date: Re: WHY: the client process has been killed, but the connection on server is still ESTABLISHED
- Previous by thread: Re: strange behavior when the client bind its UDP socket to a local address
- Next by thread: Re: strange behavior when the client bind its UDP socket to a local address
- Index(es):
Relevant Pages
|
