Work around linux DGRAM reconnect misbehaviour

[RaimoNiskanen]

In inet_drv.c I have added a simple connect call with AF_UNSPEC to clear the socket address before connecting.

For socket.erl I have added the possibility to use "native" addresses, so the same can be done from the compatibility module gen_udp_socket.erl. To be committed...

[RaimoNiskanen]

I wrote a test case.

It turns out Linux does more fishy stuff... If I bind to the wildcard address with port 0 (requesting an ephemeral port), check which port I got, then connect to 127.0.0.0:53 using a clear with AF_UNSPEC length 0 first, the source port can actually be changed by the Linux network stack. But if I bind to the wildcard address with an explicit port number, the source port does not change during clearing destination reconnect...

[RoadRunnr]

It turns out Linux does more fishy stuff... If I bind to the wildcard address with port 0 (requesting an ephemeral port), check which port I got, then connect to 127.0.0.0:53 using a clear with AF_UNSPEC length 0 first, the source port can actually be changed by the Linux network stack. But if I bind to the wildcard address with an explicit port number, the source port does not change during clearing destination reconnect...

I don't think this a bug, the behavior is documented in man 2 connect:

Some protocol sockets (e.g., TCP sockets as well as datagram sockets in the UNIX and Internet domains) may dissolve the association by connecting to an address with the sa_family member of sockaddr set to AF_UNSPEC; thereafter, the socket can be connected to another address. (AF_UNSPEC is supported on Linux since kernel 2.2.)

There is also a old bug report about this in the kernels bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=6646
It does have a final verdict from DaveM:

This behavior is intentional and will not change.

[RaimoNiskanen]

@RoadRunnr: Bummer!

I just spent a few hours on registering myself at the appropriate Linux mailing list, and writing a pretty enough C program that demonstrates the bug.

On my Ubuntu 18 the phrasing is:

Connectionless sockets may dissolve the association by connecting to
an address with the sa_family member of sockaddr set to AF_UNSPEC (supported on
Linux since kernel 2.2).

So, nothing in that about "thereafter, the socket can be connected to another address".

It seems they have chosen to classify their queer behaviour as a documentation bug.
I am not surprised.
:-(