Re: defying original 4.3BSD sockets constraint

A couple of thoughts:

1) So much software has been built that expects the existing functionality - we risk breaking / introducing vulnerability if we make an OS change; and

2) There are legitimate reasons for this functionality. For example, to stop someone from running a duplicate network client or daemon causing system issues.



Sent from my iPhone

> On Apr 17, 2026, at 18:53, Gleb Smirnoff <[email protected]> wrote:
>
>   Hi,
>
> I dared to question a constraint that we have been following for 40 years:
>
> https://reviews.freebsd.org/D56489
>
> I've been thinking of this for almost a week already and I don't see any cons.
> Pros are listed in the review - clean way to improve parallelism of connect(2).
> Maybe I am missing something?  Decided to post for a wider audience than just
> the reviews.f.o.  Please speak up if you think I am missing something!
>
> Digging through the history I have found this write up:
>
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=65928#c2
>
> and associated fix 4658dc8325e03419be1f1fa5cbda31289116a0d4.
>
> If I read the above correct, the fix is actually avoiding the constraint for a
> specific case of TCP.
>
> Attached a test program that proves that the constraint can be avoided with
> SO_REUSEADDR, thus there's no security implications.  Also proves that traffic
> would always end on the correct socket.  Program requires root, as it uses a
> raw socket for injection and also tweaks net.inet.ip.portrange.randomized.
> The program uses UDP, but our inpcb database is 99% agnostic of that.  There is
> only one spot left where it looks at so inp->inp_socket->so_type !=
> SOCK_STREAM, differentiating between TCP and UDP.  It originates exactly from
> the mentioned above 4658dc8325e03!
>
> --
> Gleb Smirnoff
> <port-steal.c>