Document listening on port 0 assigns a random unused port

[thonkle]

If port 0 is supplied, the Linux kernel will select an available port. Reference: https://github.com/torvalds/linux/blob/2c271fe77d52a0555161926c232cd5bc07178b39/net/ipv4/inet_connection_sock.c#L358

This is also true for Windows: https://docs.microsoft.com/en-us/windows/win32/api/winsock/nf-winsock-bind#remarks

Since this behavior does not appear in manpages for bind(), listen(), etc. it is not reasonable to expect node operators to know this behavior exists, so it's best to document it where they will find it: in the help text.

[DrahtBot]

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Conflicts

Reviewers, this pull request conflicts with the following ones:

• #23542 (net: open p2p connections to nodes that listen on non-default ports by vasild)

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

[luke-jr]

Since it's not documented by the APIs, it's undefined behaviour, and we shouldn't document it either (unless we explicitly add code to support it).

[ghost]

This is also true for Windows: https://docs.microsoft.com/en-us/windows/win32/api/winsock/nf-winsock-bind#remarks

I could not reproduce this on Win 10 based on below logs for bitcoind -port=0

2022-02-14T15:13:26Z Bound to 127.0.0.1:18334
2022-02-14T15:13:26Z Bound to [::]:0
2022-02-14T15:13:26Z Bound to 0.0.0.0:0

[thonkle]

This is also true for Windows: https://docs.microsoft.com/en-us/windows/win32/api/winsock/nf-winsock-bind#remarks

I could not reproduce this on Win 10 based on below logs for bitcoind -port=0

2022-02-14T15:13:26Z Bound to 127.0.0.1:18334
2022-02-14T15:13:26Z Bound to [::]:0
2022-02-14T15:13:26Z Bound to 0.0.0.0:0

The log does not report the actual listening port when 0 is selected. Try sudo netstat -pln | grep bitcoin to see what port is being used.

[sipa]

I think we should just abort initialization if port 0 is requested. It's not actually something you can listen on, and the apparently default behavior of selecting a random port is undesirable for us.

[luke-jr]

The log does not report the actual listening port when 0 is selected.

IMO that means it isn't working as described by this PR.

Do we even recognise the assigned port for addr publishing purposes?

I think we should just abort initialization if port 0 is requested. It's not actually something you can listen on, and the apparently default behavior of selecting a random port is undesirable for us.

I agree. It seems code would be needed to support a random port, and I don't see justification for the added complexity that entails. Better to just make it an error.

[ghost]

I think we should just abort initialization if port 0 is requested. It's not actually something you can listen on, and the apparently default behavior of selecting a random port is undesirable for us.

I agree. It seems code would be needed to support a random port, and I don't see justification for the added complexity that entails. Better to just make it an error.

Agree

[thonkle]

Closing in favor of a new PR to do bounds checking on -port: #24344
Port 0 is not the only case that gives unexpected behavior, so we can fix all of them at once.