TcpListener `bind`s to open port

help
1

I am having issues with TcpListener in that it will bind to an already open port.
e.g.
If I open port 8080 with nc -l 8080, and then run

use std::net::{Ipv4Addr, TcpListener};

static LOCALHOST: Ipv4Addr = Ipv4Addr::LOCALHOST;

fn main() {
    let port = 8080;
    let is_ok = TcpListener::bind(format!("{LOCALHOST}:{port}")).is_ok();
    dbg!(is_ok);
}

is_ok will be true, indicating the TcpListener was able to bind to the already open port.

What am I misunderstanding here? My end goal is to be able to tell if a port already has a process listening on it.

I'm running macOS 13.0.

1 Like
2

I can reproduce this on macOS 11.7.2. I can get is_ok to be false by running nc -l 127.0.0.1 8080 instead of just nc -l 8080. Apparently, netcat is listening by default on some interface other than loopback.

1 Like
3

Interesting, the same thing happens for me. The actual context is I am using zmq to communicate with a local server. The zmq server is binding on tcp://*:8080 with a REP socket, and the client is connecting to 127.0.0.1:8080 with a REQ socket.

It seems like it could be a related error with the server listening on all interfaces. Any thoughts?

4

To confirm, changing to listen on tcp://127.0.0.1:8080 solves the issues.

Can somebody explain why listening on broadcast (*) still allows another listener to bind on the same port?

5

There's no such thing as an "open port" in isolation; port numbers only mean anything when combined with an address. If your machine has, say, 5 different IP addresses, then there can be up to 6 different sockets all bound to the same port - one for each IP address, and one more for the wildcard address (0.0.0.0, also shown as * in some contexts).

The wildcard address binding will be used if there is no more specific address binding that applies - if you have a socket listening on 127.0.0.1:8080 and another listening on 0.0.0.0:8080 then an incoming connection to 192.168.0.1:8080 will be handled by the wildcard socket, but an incoming connection to 127.0.0.1:8080 will not.

None of this is related to broadcasts.

5 Likes
6

Ahh. Thank you very much for the clarification.

7

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.