Re: Question about tcp ephemeral ports

[Eric Haszlakiewicz <erh%nimenees.com@localhost>]

On Mon, Jan 30, 2012 at 03:39:50PM +0100, Olivier MATZ wrote:
> 
> /*
>  * Create two tcp servers. Try to connect many clients to the first
>  * server. Once the maximum number of ephemeral ports is reached, it
>  * should fail. Then try to connect the other server which is bound to
>  * another port. Linux and NetBSD have a different behaviour.
...
> The last line shows that on Linux, the application is allowed to do the
> connect() if the destination port is different. On NetBSD, the connect()
> will fail as soon as the maximum number of ephemeral ports is reached.
...
> I would like to have some expert opinions about this behaviour. Is there
> a workaround? Is there a need to patch the kernel? I would answer yes
> because I don't see any obvious way to have more than several thousands
> of TCP clients with one source address. Also, I wonder if this behaviour
> could be used to do a deny of service and prevent other applications to
> do their connect().

The code that actually picks the ephemeral port to use is in netinet/rfc6056.c.
At first glance, it looks like it *should* allow your code to work: regardless
of the algorithm used to cycle through the port numbers, the 
check_suitable_port() function uses the address to verify that the port is
available.

If you can build a kernel with options RFC6056_DEBUG, and try your test again
it should emit enough info to figure out what's going on.
This looks like it would be more than just a "patch".  You'd need to rewrite
the ephemeral port selection code in netinet/rfc6056.c, which currently 
doesn't looks like it considers the source address at all.  

eric