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
