From: Tobias Klausmann (klausman_at_schwarzvogel.de)
Date: Tue 11 Nov 2003 - 13:54:50 GMT
Hi!
On Linux systems, binding the same port twice fails with
EADDRINUSE. If you need two filedescriptors referring to the same
socket, you're supposed to dup() the first one.
The attached program illustrates this point. It creates two UDP
sockets and binds them to a hardcoded IP and port.
On a vanilla Linux, the second bind fails as expected:
$ ./bind_err
First bind ok
Second bind failed: Address already in use
$
On vserver-patched Linuxes I have a different behaviour:
- If the IP to be bound is 0.0.0.0 and chbind is not used , the
second bind fails as expected with EADDRINUSE
- If the IP is set to something different (e.g. the IP of eth0),
both binds succeed and lsof shows this:
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
bind_err 2829 klausman 3u IPv4 16379 UDP 192.168.0.1:7777
bind_err 2829 klausman 4u IPv4 16380 UDP 192.168.0.1:7777
netstat agrees:
Proto Recv-Q Send-Q Local Address Foreign Address State
udp 0 0 192.168.0.1:7777 0.0.0.0:*
udp 0 0 192.168.0.1:7777 0.0.0.0:*
- If the IP is set to 0.0.0.0 and chbind --ip 192.168.0.1 is
used, both binds succeed and the behaviour is the same as
above (the IP shown is 0.0.0.0, not 192.168.0.1).
Now while one could argue about what's right (allowing double
binds and what the resulting behaviour should be), it's
definitely inconsistent with the behaviour of the unpatched
kernel. IMNSHO this is bad and wrong.
I know that older versions of the patch were consistent and I
guess this effect was introduced when the
"netstat-prettification" (Showing 0.0.0.0 in netstat even if
chbind was used, IIRC) was introduced.
The trouble with this is that some third-party non-opensource
software tries to bind a port, starting at 7777 and incrementing
if it fails. It then tries to bind another bind another port for
different purposes, again starting at 7777. On vanilla Linux,
this results in two sockets, one 7777, one 7778 and everything is
peachy. With vservers, the program also has two sockets, but both
at port 7777. Granted, the program behaviour is stupid, but there
is nothing I can do about it right now. Plus, as I said above,
it's inconsistent with the vanilla kernel, which is bad in
itself.
What (if anything) will be done about this?
Greets,
Tobias
-- Thank you for calling $PROVIDER helpdesk. If your cupholder is broken, please press 1. If you want an actual knowledgable support person, please enter the IP representation of a /28 netmask."