I have a feeling what sometimes :0 is interpreted as a 'first listening'. But Occam says what most of the time it's just 'DNAT dst port ANY to :80' or whatever, no magik.

I saw the URL and immediately thought it was about Acid Pro DAW or Vegas video editor is used to use back in the early 00’s.

Sometimes I have scripts that automatically assign ports starting from 30000. How would that work? Would I have to bind to port 0 multiple times until I randomly get a port in that range?

I'm not quite sure what a script assigning ports actually does, but if I need an app to bind a port in some port range, I just start binding ports starting from 30000 until it succeeds.

If it's in a script then that might be difficult, but a racy approximation could be to loop e.g. listening socat with different ports for finding the free port. (Or maybe: parse output of ss.) But if the port use is separate from the port binding, then it might still be busy once the time to rebind it comes.

I’m not exactly sure if that’s the question, but the range can be set. Here’s the Linux solution: https://tldp.org/LDP/solrhe/Securing-Optimizing-Linux-RH-Edi... FreeBSD has net.inet.ip.portrange

That might not quite fit my use case. My AI-generated scripts probably won't modify system-level configuration files to change the port range

I'm not sure how I'd do acceptance/E2E testing without the magic of port 0. As long as you have a way of capturing what port it ended up using (which most languages are able to out of the box more or less), parallelizing testing workloads becomes such a breeze without having to manage ports and all that jazz, just fire everything up with N parallism and let the OS figure out what the free ports are, pass the references down and stuff just works. Thanks Linux :)

> I'm not sure how I'd do acceptance/E2E testing without the magic of port 0.

Same as anything else, an explicit flag to achieve the same "just give me a port" functionality as this "magic number" does without resulting in the documented unpredictable behavior around a technically legitimate port number.

As the article points out, most if not all of the services exposed on port 0 seem to be accidental and likely resulted from people assuming this magic behavior applies everywhere instead of just to one specific API.

And then there is OpenSSH...

    joker@joker:~$ ssh localhost -D 127.0.0.1:0
    Bad dynamic forwarding specification '127.0.0.1:0'
    joker@joker:~$ ssh localhost -D 127.0.0.1:9999
    ssh: connect to host localhost port 22: Connection refused
    joker@joker:~$ ssh localhost -L 127.0.0.1:0:localhost:8080
    Bad local forwarding specification '127.0.0.1:0:localhost:8080'
    joker@joker:~$ ssh localhost -L 127.0.0.1:9999:localhost:8080
    ssh: connect to host localhost port 22: Connection refused

Oh well.

Seems hugged?