Re: defying original 4.3BSD sockets constraint

Michael Tuexen <[email protected]>
Newsgroups gmane.os.freebsd.devel.net
Message-ID <[email protected]>
> On 18. Apr 2026, at 03: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!
I think the sequence of bind() operations is not important.

If I understand you correctly, you say bind(specific) after bind(wildcard)
is bad, since the instance of bind(specific) is stealing packets.

The same applies (in my view) for bind(wildcard) after bind(specific).
If bind(wildcard) succeeds, the caller assumes that it gets all packets,
but that is not true.

The only difference is when the "stealer" took action.

Best regards
Michael
> 
> 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>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.