[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Question about tcp ephemeral ports
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
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.
Main Index |
Thread Index |