ephemeral ports and port re-use for socket_wrapper emulated TCP bind()
asn at samba.org
Thu Oct 20 06:54:28 UTC 2016
On Thursday, 20 October 2016 12:08:55 CEST Andrew Bartlett wrote:
> I've found an interesting issue while working our Samba's RPC server.
> I wanted to change Samba from listening only on 1024 to listening on
> many ports for ncacn_ip_tcp so that I could multi-thread our netlogon
> The most practical way to do that is to have it listen on a distinct
> However, because swrap_bind has the (new, at that point)
> check_addr_port_in_use() function removed with an #if 0 by commit
> 064592d9cb6349e625b881cfcfab37b19d141ebe, no check is made to see if a
> socket is available.
This is code is commented out because
a) it is incomplete
b) it doesn't have tests
The way to fix this is to start working on a) and b). Well, implement b) first
However this is limited to one process, the process socket_wrapper is
preloaded. It will be possible to check that as soon as socket_wrapper has a
database. This is the work being done do make it thread safe and support fd-
> This means we just unilaterally unlink() the socket.
> This broke this loop in stream_setup_socket() where we (yes, really...)
> loop from 1024 up, binding on each port trying to get a free port!
> In my patched case that put each ncacn_ip_tcp services on a new
> endpoint (binding), it meant that we had 10 difference services
> listening on 1024, the last of which was the only one actually able to
> be contacted! :-)
> So, given the limitations of unix domain sockets (it seems impossible
> to determine without making a connect() if the socket is currently
> bound by someone else), it seems the options are to:
> 1) specify the port in a config file
> 2) change the code to use 0 for a real ephemeral port and use the code
> in swrap_auto_bind() to produce it
> 3) add some kind of lock file or (non-portably) use an fcntl() lock on
> the socket to determine if it is bound.
> I'm thinking to just do option 1 (with the advantage that many of our
> users would like to be able to control these ports), but in the
> meantime do you have any other suggestions?
Why don't you want to improve socket_wrapper?
Andreas Schneider GPG-ID: CC014E3D
Samba Team asn at samba.org
More information about the samba-technical