Python 3.11 removed reuse_address paramter

[gsauthof]

It turns out that Python 3.11 removed the reuse_address keyword parameter from its connection functions.

Thus, this make asyncssh fail on Python 3.11 - i.e. it breaks many test cases:

https://bugzilla.redhat.com/show_bug.cgi?id=2028064

See also:

• https://docs.python.org/3.11/whatsnew/3.11.html#removed
• https://bugs.python.org/issue45129

So it seems that a simple fix is to remove all the reuse_address keyword argument passing in asyncssh/connection.py. AFAIU, the parameter isn't really usable in the last few Python releases, anyways, due to it yielding a ValueError, when set.

[ronf]

Thanks for the heads-up, Georg. I wonder if this might be a mistake, though. According to the references you list here and looking at the the previous deprecation, it only applied to create_datagram_endpoint() and not create_server(). So, I wonder if the complete removal of this argument in python/cpython@59ea704 was actually correct. It looks to me like this should only have been done for create_datagram_endpoint(). If the intention is to eventually deprecate this feature for both UDP and TCP, I think some additional time should be given to deprecate it in create_server() before it is completely removed there.

I tested this option against 3.6 though 3.10 and confirmed there was no deprecation for the way AsyncSSH is using reuse_address and no ValueError raised, since it only ever uses it in create_server. I can also confirm this breaks in 3.11.0a1, but I'm going to wait until I can confirm that the removal from create_server() was intended before I change anything in AsyncSSH. I've added a question to commit python/cpython@59ea704 asking about this.

[gsauthof]

I agree, removing it also for TCP doesn't make much sense.
Even more so without any previous deprecation.

FWIW, I haven't heard about any security issues when using SO_REUSEADDR on TCP sockets - at least on Linux/UNIX systems. AFAIU, there SO_REUSEADDR is primarily used to bind to ports that are still in TIME_WAIT.
However, Windows seems to implement that option differently.

[ronf]

The removal of this argument from create_server was indeed a mistake. It has been fixed in python/cpython#29733.

In a quick test, I don't see the round-robin behavior described in the original report related to datagram sockets, but Windows does appear to allow listeners to be opened on the same port from two different processes at once when reuse_address is set. In that case, the original listener seemed to get all the traffic, but once it exits the other process starts to receive the traffic. This can happen even when the processes are running as different users, but is subject to the usual restrictions about privileged ports. Also, unlike the UDP case, this is not the default behavior. You have to request it explicitly with reuse_address=True and if the original process didn't also use reuse_address=True, the new process gets a permission error (whether it is the same user or not).

So, basically, trying to open a second listening process on the same port is only allowed in Windows if all instances use reuse_address=True explicitly, and even then it doesn't appear you get any load balancing. The main benefit is that a process can restart on a previously open port more quickly without waiting for existing connections to time out, which is similar to the UNIX behavior.

Interestingly, attempting to open simultaneous listeners on Linux fails even with both processes setting reuse_address (which is the default). It only helps if the original process has exited but there are still sockets in TIME_WAIT. If you try to open simultaneously listeners, the second process gets an error unless both processes set reuse_port=True. When they do, they can not only both listen on the port at the same time, but Linux will also round-robin the requests across both processes.

I also tried setting both reuse_address and reuse_port on Windows, but that just comes back with an error saying that reuse_port is not supported by the Windows socket module.

So, from a security standpoint, I think everything is good here, and with the create_server argument restored the errors you saw in AsyncSSH in Python 3.11 should no longer be a problem.