Port in use - keeping track of 188x ports opened

Just a warning for others to remind/alert that MQTT brokers commonly use port addresses starting with 188x and if you add in extra node-red alternate testing installs - its easy to come into conflict with them - like what I did!

So on my Pi4 - I am developing in an alternate install that uses 1883 (I've already got other testing installs running on ports 1881 and 1882)

That is my first error, because if I was to add in an mqtt broker, it is going to default to 1883 so I'm recommending never using that port for Node-RED :slight_smile:

Moving on, I wanted a test alternate install so I set up one on port 1884 but kept getting port in use in the log - couldn't understand why - so rebooted and it came back up with my main NR on port 1880 - nothing else running (or so I thought)

Launched my alternate install on port 1884 - port in use again.

Eventually, the penny dropped - I'd installed a test broker using the Aedes node and had set it to use port 1884!

So, I think in future, I'm going to use 1888x for alternate installs :slight_smile:

1 Like

Also be aware when picking ports, if you are using Cloudflare as a proxy, that most ports are blocked.

This is a list of Ports that the Cloudflare proxy allow you to use - https://support.cloudflare.com/hc/en-us/articles/200169156-Identifying-network-ports-compatible-with-Cloudflare-s-proxy

1 Like

For linux users, which includes Raspbian, you can use the netstat command, to view information about current open ports. Then, piping the output into grep, you can show only commands on the 188x(x) ports.
For that, the command would be sudo netstat -plnt | grep ':188*'
netstat -plnt will run the netstat and give output including the program keeping that port occupied with the PID (-p), only the programs that are listening (-l), show the numerical addresses rather than a description (-n) and request the information specifically to TCP (-t). Running the command as sudo then gives information on all active listeners, so not just for the current user. That is important here as you need all listening ports on that range, not just those of the current user.
Then, by searching through the output with grep for ':188*' will look for the end of the addresses, so ports specifically, and for ports that look like 188 with a wildcard behind it. So that's 188, 188x, 188xx.


For example on my Pi 3B+, it shows like this:

pi@neela:~ $ sudo netstat -plnt | grep ':188*'
tcp        0      0  *               LISTEN      365/node-red        
tcp        0      0  *               LISTEN      460/mosquitto       
tcp6       0      0 :::1883                 :::*                    LISTEN      460/mosquitto     

where the header of the columns is cut off by grep, but would be like this:

Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name

I tried using that but due to the fact that the port is open due to a running a broker as a node - it fooled me into thinking that I had another node-red instance already running on 1884 - I spent ages trying to find out where it was being launched from!!! :grimacing:

Wasn't until an old memory cell came out of hibernation that made me check my main 1880 install and found the Aedes broker using port 1884

Maybe when I have same problem again - the difference between the ipv4 and the ipv6 0 ::: x will jolt my memory sooner :slight_smile:

1 Like

oof, I hadn't thought of that yet, brokers within Node-RED. Don't think there's an easy way to distinguish those easily, but if you look closely to the rightmost column, it shows as PID/program, and for the 1884 port it has the same PID as the node-red instance on port 1880 (both showing as "1200/node-red", so that might be your way of noticing the differences.

1 Like

Well spotted :slight_smile:

Generally, if you are exposing micro-services to the outside world, it is advisable to put them behind a proxy. Doing that lets you run them from the standard https port 443 and put them onto virtual folders.

It also, of course, means that you can more easily provide a robust and updatable https (Caddy is especially good for this), keep the service alive using things like Phusion Passenger and overlay authentication and authorisation services. You can also do load balancing and high-availability should you need to.

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.