Subject: [Patch] SO_REUSEADDR fix in ipv4/ipv6 (n connects + 1 listen)

From: "Ilya Pashkovsky" <[email-masked]>
Date: Wed, 15 Dec 2004 18:08:13 +0200

Hello, fellow developers.
This is a proper documentation for the reuse patch, along with
its adoption for 2.6.10rc3-mm1 patchset.

Current implementation of SO_REUSEADDR in the kernel disallows
same port binding if a listening socket is already bound to it.
This limits the options for firewall/nat piercing for applications,
and is non-standard.
The current limit was made because of the security risk
of allowing free binds to same socket. This allowed listen
call preemption and, since no unambiguous and secure fix
was not found, the option to reuse port after listen-bind
was removed. (the problem is that of multiple listeners
bound to same port. this patch does not fix it, since the
behaviour is ambiguos and not defined clearly, though maybe
a userid check along with another flag telling to allow listen
preemption (SO_REUSEPORT can be reused for this purpose) may
solve that.)

Also, SO_REUSEADDR option value is boolean, but is checked
to be more than 1 in code. This check was removed.
The way multiple listeners was removed is by disallowing
any reuse of a port with a bound listener. This is implemented
by a check in tcp_ipv4.c (and tcp_ipv4.c) in function
tcp_bind_conflict(). There's a check for any existing sockets
matching the source port and having a TCP_LISTEN state.
This check was changed to allow binding unless the new
socket is also in TCP_LISTEN state. This still disallows
multiple listeners but allows reuse of the port for
outgoing connections. This check is made/modified in both
ipv4 and ipv6 code.

Testing was done using normal workloads on 2 i386 linux
installations with normal workloads and also the netcat test.

Test with netcat (uses SO_REUSEADDR by default):
host A: nc -v -l -p 9999
host B: nc -v -l -p 9000
host A: nc -v -p 9999 host.B.ip.addr 9000
host B: nc -v host.A.ip.addr 9999

host A and B can be same host.

Testing did not reveal any problems and networking software
worked fine in both ipv4 and ipv6 networks.

Signed-off-by: Ilya Pashkovsky <[email-masked]>

--

-- 
  ilya