simon.schönbeck.dk

Tag: port

  • “Unable to load stream. Please make sure port 7446 is open on your NVR.”

    In case you are seeing the error message “Unable to load stream. Please make sure port 7446 is open on your NVR.” when trying to watch the live camera stream on your Unifi Video NVR system from Ubiquiti, then the solution is rather simple.

    The error is caused by the self-issued certificate that comes by default with the Unifi NVR. As Mozilla Firefox has strict SSL (HTTPS) rules making sure that one does not connect to the wrong or fake website as could happen in e.g. a phishing attempt. I have not tried myself but from what I have read apparently Google Chrome does not enforce this in the same manner making the stream work out of the box in Chrome.

    The solution is to open the URL to the video stream directly in a separate tab or window so that you can accept the self-signed certificate for the session:

    https://NVR_IP_address:7446

    The page itself will return an error after the certificate is accepted but that is fine, it is simply to accept the certificate. After that simply reload the NVR interface and the HTTPS video stream will work fine

    Please note that if you are accessing the NVR from an external network you may have a firewall instance blocking the actual port. This instead would require port forwarding to be set up and that is a different story.

  • Which process at which port?

    I came back to the computer earlier today and found one of my servers to be unresponsive. The front-end of one of my bittorrent hosting boxes did not load so I tried some of the other websites hosted on the same box. None were loading.

    Luckily accessing via SSH worked fine and revealed that Apache had died for unknown reasons at some point from yesterday onwards. Trying to start Apache was not possible since it could not bind to the socket at port 80. I had already checked for any remaining PIDs from the previous httpd process, so I started worrying about a possible intrusion or some root-kit binding to port 80 instead of Apache.

    I started running netstat to reveal the listening ports but unfortunately the process information field was empty for this particular process in question. A quick search showed how lsof could also be used to display the name and pid of the listening process on any port number. In my case I typed:

    lsof -i :80

    This displayed a couple of known Python orphaned processes that belonged to the original and defunct httpd process. Once killed Apache was started with no issues.

    After all, nothing dramatic!