listen port already in use

[t0000]

Hi, in version 1.8.4 the bot automatically selected a new port when the other was occupied.

Example:

listen 17050 users listen 14050 bots

if 17050 is already occupied, the bot has automatically changed to 17051

now the bot can no longer be started:

Tcl error in file 'eggdrop.conf': Couldn't listen on port '17050' on the given address: Address already in use. Please check that the port is not already in use while executing "listen 17050 users"

the same with "bots"

there are always times that an eggdrop restarts and the port is not directly released

[vanosg]

Hi @t0000 , thanks for taking the time to register this with us. This was an intended change and functionality as part of 1.9.0; the counter-point to your report was that bots would begin to listen on ports not specified in the config file and thus, not be able to relink when they started back up.

Can you provide a little more info on what scenario you encountered this issue? Generally we've found modern OS's are able to properly handle releasing ports in most cases. Was this after a normal restart? As a result of a script? etc etc. Any info you can provide would give us some good context so we can make sure we're incorporating all viewpoints into our design decisions. Thanks!

[michaelortmann]

eggdrop tries to set SO_REUSEADDR to the socket before bind()ing the listen port to prevent this issue: https://github.com/eggheads/eggdrop/blob/9f6bbd60f40f869f46fa4042c40f8ba46c6d2560/src/net.c#L391 Maybe eggdrop could not set SO_REUSEADDR? Unfortunately the debug output for a failed setting of SO_REUSEADDR is only visible if eggdrop is started with -n and not if it is started with -t (#627 is about the missing debug output issue): https://github.com/eggheads/eggdrop/blob/9f6bbd60f40f869f46fa4042c40f8ba46c6d2560/src/net.c#L392

[michaelortmann]

The main reason for "occupied port" aka EADDRINUSE (The specified address is already in use.) is TIME-WAIT. TIME-WAIT is part of TCP protocol design, see https://en.wikipedia.org/wiki/Transmission_Control_Protocol#Protocol_operation For example under linux one could get information about connections in time-wait with ss --numeric -o state time-wait Result would look like

Netid      Recv-Q      Send-Q            Local Address:Port             Peer Address:Port       Process                        
tcp        0           0                     127.0.0.1:6667                127.0.0.1:59974       timer:(timewait,51sec,0)

Other systems have netstat or other tools to do so.

TIME-WAIT is only entered by the endpoint of a connection that initialized the closing of the socket.

So, because the "port in use" is "wanted" by tcp protocol design, by operating systems, to be expected and happing with about any software out there, there wont be a "FIX" for this PR. This also is not a regression in eggdrop 1.9, for, as vanosg stated, the old behaviour / workaround had bad side effects and was removed for good. I readied a new workaround with #1143, but such a workaround is unseen in other software and after discussion on irc, also i wont press for #1143 to be merged. I hope my documentation in this PR helps in understanding some of the details and as something we can refer to, should this issue be brought up more often with eggdrop 1.9, since it is a user visible change that needs explanation, or in the future.

[kh262]

hi any update?