On Mon, 20 Sep 2010 12:00:41 +1200, Lawrence D'Oliveiro wrote: >> However, some clients choose their own source ports. E.g. rlogin/rsh use >> privileged (low-numbered) ports, and you can't get the kernel to choose a >> random privileged port for you. > > But nobody uses rlogin/rsh any more,
They did when the bind() and SO_REUSEADDR semantics were developed. If they were doing it now, chances are that SO_REUSEADDR would be enabled by default. > and who would attach any trustworthy > meaning to a connection coming from a remote low-numbered source port? If you receive a connection with a low-numbered source port and it *isn't* legitimate, then someone has got root (in which case any other authentication mechanism isn't safe either) or someone has hijacked the IP address (you do know that low-numbered ports are only meaningful for systems under your control, right?). Using a firewall rule which only allows connections from a low port on specific IP addresses certainly isn't any worse than a rule which only allows connections from any port on specific IP addresses. That's true regardless of whether the protocol includes other authentication mechanisms. >> If you're writing a server which listens on a known port, you *should* be >> using SO_REUSEADDR to avoid unnecessary delays in start-up. The kernel >> will automatically reject packets relating to stale connections, and your >> server should be accepting any new connections ASAP. > > That makes it sound like SO_REUSEADDR should really be a superfluous option. > But it’s not. Well it is mostly superfluous. It should always be enabled for a server listening on a known port, and doesn't matter for a client which uses ephemeral ports. -- http://mail.python.org/mailman/listinfo/python-list