strange behavior when the client bind its UDP socket to a local address

Hi,
I do a simple test with netcat and tshark.

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 ???
(and not from 127.0.0.1 to 192.168.75.62)
I do not see this strange behavior in TCP.

Regards,
Christophe.

On Jan 16, 5:04*am, Christophe Lohr <christophe.l...@enst-bretagne.fr>
wrote:
> Hi,
> * I do a simple test with netcat and tshark.
>
> 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 ???

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.

> (and not from 127.0.0.1 to 192.168.75.62)

Why would it deliberately pick a worse address?

> I do not see this strange behavior in TCP.

Because in TCP there's only one connection, and you force it to use
the worse address, so it has no choice.

DS

David Schwartz a écrit :

> Normally, the networking stack will try to pick the closest source
> interface address it can.

Fine, thank you!

Christophe

Hello,

David Schwartz a écrit :
> On Jan 16, 5:04 am, Christophe Lohr <christophe.l...@enst-bretagne.fr>
> 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.

David Schwartz a écrit :
> On Jan 16, 5:04 am, Christophe Lohr <christophe.l...@enst-bretagne.fr>
>
>> 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 ???
>> (and not from 127.0.0.1 to 192.168.75.62)
>
> Why would it deliberately pick a worse address?

I am not conviced: the third message is an ICMP Error...
Replying from the contacted address would really be a worse idea?

Christophe

Pascal Hambourg a écrit :
> This looks like a bug to me.

You mean a bug in Linux?

On Jan 19, 4:38*pm, Pascal Hambourg <boite-a-s...@plouf.fr.eu.org>
wrote:

> > 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.

No platform I know of "remembers" that a UDP datagram was received
with a particular destination address and uses that as the source
address for subsequent datagrams. In fact, that's a crazy thing to do.

> 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.

Sure, that's why many *applications* do this. But this question is
about an application that doesn't.

> 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.

Yes, a bug in whoever invoked the server. If the person invoking the
server knows the client requires UDP datagrams to have a particular
source address, they must inform 'nc' of this, by using the '-s'
option.

DS

On Jan 20, 11:59*pm, Christophe Lohr <christophe.l...@enst-
bretagne.fr> wrote:
> Pascal Hambourg a écrit :
>
> > This looks like a bug to me.
>
> You mean a bug in Linux?

No, a bug in the person who invoked the 'nc' server without telling it
what source address to use in a context where the client cares what
source address is used. See my other post.

DS

Christophe Lohr a écrit :
> Pascal Hambourg a écrit :
>> This looks like a bug to me.
>
> You mean a bug in Linux?

No, in nc.

David Schwartz a écrit :
> On Jan 19, 4:38 pm, Pascal Hambourg <boite-a-s...@plouf.fr.eu.org>
> wrote:
>
>>> 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.
>
> No platform I know of "remembers" that a UDP datagram was received
> with a particular destination address and uses that as the source
> address for subsequent datagrams. In fact, that's a crazy thing to do.

If by "platform" you mean "OS", I didn't mean that.

>> 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.
>
> Sure, that's why many *applications* do this.

Not only because of stateful filtering, but also because IMO it just
makes sense to do so, so that the client can identify the reply more easily.

> But this question is about an application that doesn't.

Yup, and I claim that this application, namely nc, is broken.

> If the person invoking the
> server knows the client requires UDP datagrams to have a particular
> source address, they must inform 'nc' of this, by using the '-s'
> option.

By doing so you limit the nc server to accept communications only on one
address instead of any local address.