Re: defying original 4.3BSD sockets constraint

On Fri, 17 Apr 2026, Gleb Smirnoff 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.

I remember about 7 iterations with Robert back then in 2008(?) to get all the
PCB code right for multi-IP jails.

I believe plain-IP jails are still relying on the fact of "stealing" and
non-"stealing" somewhere (not sure in this piece) and what is possible but
I do not know if this is related to this code; it's documented in jail(8).

Checking the code with blame I see my name is only left on a blank line
and a } so the answer is I have no idea anymore.  Someone should write
regression tests for this if we have not already to see that they do not
break.


> 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

Yes, there was a case in the code where we would return an inpcb based on the
assumption that not both callers would reuse SO_REUSEADDR (or PORT?)?

> 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!
>
>

-- 
Bjoern A. Zeeb                                                     r15:7