Tag: Ubiquiti

  • AF60-LR Ethernet Carrier Drop option missing

    Dealing with rain on a 60 GHz radio link can be tricky. It works flawlessly with high capacity in the Gbit range when the weather is nice. Once raindrops start pouring down the link will degrade to a point where it may drop the connection completely, all depending on precipitation level and radio frequency/channel selection.

    When running OSPF over such a wireless bridge there is no indication that the link has failed until the next “Hello” receives no answer from the neighbouring router and the “Dead Interval” is reached. At this point the link would be brought down by OSPF and assuming there are redundant paths, traffic would be routed through another part of the network to its final destination.

    The problem here is the long time the link is reported as being up by OSPF when it is really down. This means traffic is being sent through this dysfunctional path and getting nowhere for as long as the duration of the OSPF “Hello” plus “Dead Interval” timer. Of course one could decrease this timer to a bare minimum, however in a wireless network there could be some brief interference at times which usually would not last long enough for the user to notice. It also increases load on the routers and albeit minimally, the network itself due to the extra packets.

    What we really need is the same experience for the router as if the network cable was to be pulled out of its port socket. The OSPF process would immediately bring the interface down and the path would no longer exist in the OSPF topology database. Traffic would be routed without delay and any downtime via the redundant path. Here is where Ethernet Carrier Drop comes into the picture. As described by Ubiquiti itself in the info label:

    Carrier drop monitors your link and disables Ethernet interface in case downlink capacity drops below configured threshold.
    Port is disabled, if capacity remains below threshold for Carrier Down delay.
    Once capacity exceeds specified threshold for Carrier Up delay, port will be enabled.

    I needed a link consisting of a pair of Ubiquiti 60 GHz airFiber (AF60-LR) to use Ethernet Carrier Drop when rain faded the signal strength killing the connection. The pair runs in a Master & Station mode so wireless configuration is done in the Master and propagates to the Station. However I could not find the Ethernet Carrier Drop selector anywhere. Looking through all the setting pages revealed nothing, however I knew it was present in the firmware.

    Digging around I found a reference to the feature in the old 2021 2.5.0 firmware change-log:

    - Ethernet Carrier Drop is configured on the Station side of the link. When Station DL capacity drops below configured threshold, Ethernet port will be disabled. Management will be available only via wireless link.

    So there you go, the Ethernet Carrier Drop feature is actually in the Station and not the Master wireless settings page.

    I guess the logic behind it is that usually the Master peer is more centrally located in the network topology and the Station in the remote branch. One cannot access the device while the Ethernet port is disabled, so if done on the Master one could be locked out from doing any further configuration changes. Still, it is a bit curious the feature is not explained anywhere apart from in a four year old firmware change-log.

  • “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.