On the test, I will flash Rocket M5 with XM 5.6.5 firmware for version 6.1.8.
I will describe the update procedure:
Continue reading “Rocket M5 firmware update”Vyacheslav Gapon – personal blog, manuals, articles, notes, development
On the test, I will flash Rocket M5 with XM 5.6.5 firmware for version 6.1.8.
I will describe the update procedure:
Continue reading “Rocket M5 firmware update”For the test, I’ll take the airMAX Rocket M5 sector antenna in bridge mode and the airMAX NanoBeam M5 client antenna in router mode.
Restrict access first to the client.
Suppose that it is connected to the sector and has an IP address 192.168.110.40 which looks into the Internet (obtained via DHCP).
The IP of the administrator who should have access to it remotely is 10.10.10.5, the rest must be blocked.
And so, go to the airMAX NanoBeam M5 web interface, open the “NETWORK” tab, next to “Configuration Mode:” select “Advanced”, then more settings will appear.
At the bottom where the “Firewall” tick the “Enable”.
Just below we add a rule specifying:
Target: DROP
Interface: WLAN0
IP Type: TCP
Source: 10.10.10.5 (IP from which it is allowed to connect, as well as be sure to put a tick in front of it under the exclamation mark)
Port: leave empty
Destination: 192.168.110.40 (An antenna IP that looks out)
Port: 22 (This is an SSH port, similarly, other rules are created to restrict access to the HTTP port – TCP 80, HTTPS – TCP 443, Telnet – TCP 23, SNMP – UDP 161, Discovery – UDP 10001)
As you can see, this rule blocks all TCP connections to port 22 of the WLAN0 interface on IP 192.168.110.40, and the set check mark on ! before Source: 10.10.10.5 means that everything except this IP is blocked.
Click “Add”, then “Change” at the bottom and at the top of “Apply” to apply the changes, after that the antenna will restart.
To limit access to the sector antenna that is configured by the bridge, we add the same rules, only where the Interface: we specify ANY (ALL).
Is done.
After adding rules and connecting to a device via SSH in the configuration, you can see the following:
ebtables.status=enabled ebtables.1.status=enabled ebtables.1.cmd=-A FIREWALL -p 0x0800 --ip-protocol 6 --ip-src ! 10.10.10.5/32 --ip-dst 192.168.110.40/32 --ip-dport 22 -j DROP ebtables.1.comment= ebtables.2.status=enabled ebtables.2.cmd=-A FIREWALL -p 0x0800 --ip-protocol 6 --ip-src ! 10.10.10.5/32 --ip-dst 192.168.110.40/32 --ip-dport 80 -j DROP ebtables.2.comment= ebtables.3.status=enabled ebtables.3.cmd=-A FIREWALL -p 0x0800 --ip-protocol 6 --ip-src ! 10.10.10.5/32 --ip-dst 192.168.110.40/32 --ip-dport 443 -j DROP ebtables.3.comment= ebtables.4.status=enabled ebtables.4.cmd=-A FIREWALL -p 0x0800 --ip-protocol 17 --ip-src ! 10.10.10.5/32 --ip-dst 192.168.110.40/32 --ip-dport 161 -j DROP ebtables.4.comment=
See also my article:
Ubiquiti SSH control
UNMS (Ubiquiti Network Management System) – EdgeMAX®, EdgeSwitch®, airMAX®, UFiber device management system, which includes software updates, configuration backup, real-time performance graphs, notifications, device location maps, etc.
For example, I will install UNMS on Ubuntu Server 18.04 64bit.
First, install the necessary components:
sudo apt-get update sudo apt-get install curl sudo bash netcat
Download the installation script from the official site to the temporary directory:
curl -fsSL https://unms.com/install > /tmp/unms_inst.sh
Run the downloaded script:
sudo bash /tmp/unms_inst.sh
If it is necessary to change the web ports during the installation:
sudo bash /tmp/unms_inst.sh --http-port 8080 --https-port 8443
By default, UNMS uses Let’s Encrypt when creating SSL certificates for your domain and saves them in /home/unms/data/cert/live.
If you want to use your SSL certificates, then during installation, for example, we specify (UNMS should have read rights in ssl-cert-dir):
sudo bash /tmp/unms_inst.sh --http-port 8080 --https-port 8443 --ssl-cert-dir /etc/certificates --ssl-cert fullchain.pem --ssl-cert-key privkey.pem
It happened when during the process of updating the firmware of RocketM, NanoBeam, NanoStation and other Ubiquiti devices power was lost, or there were some other problems after which the device could not be accessed via the web interface and it did not work.
Continue reading “Ubiquiti (UBNT) device recovery”Once I noticed the spread of the virus/exploit on the network with Ubiquiti devices. Exploit using a vulnerability in older versions of firmware copied itself to other devices and from them attacked the following.
Continue reading “Removing exploits from Ubiquiti devices”I once treated Ubiquiti Networks airMAX® M Series devices with firmware 5+ from the exploit and updated the firmware to the latest, at that time it was the version of XM 6.0 and XW 6.0.
See my article – Removing exploits from Ubiquiti devices
In the 6.0 firmware, the vulnerability was removed through which the exploit was accessed, but there were other bugs.
Literally a couple of weeks later I noticed that there are no connected stations on some bridges in the Access Point (AP) mode, power was lost from the station, the station was booted and connected to the AP, but the AP did not show the connected stations and the traffic did not pass, it’s just and there is a bug.
Solve the problem by restarting the AP, in the future, if the power supply was lost again on the station or it was reboot, there was a high probability of a repetition of this problem.
Fortunately, this problem was later eliminated in new firmware, I did not exactly look at which version, but on devices with firmware 6.1+ it was no longer observed.
In normal mode, airMAX sends a confirmation frame (ACK) after receiving the data frame, but at longer distances, it is better to disable this mechanism by setting the Long Range PtP Link Mode checkbox in the settings.
Depending on the channel width, the distance at which you want to turn on the Long Range PtP Link Mode can be different.
40MHz: 16.5 miles (26.5 km)
20MHz: 35.6 miles (57.3 km)
10MHz: 72.3 miles (116 km)
5MHz: 144.7 miles (232.9 km)
Note: this information does not apply to airOS 7, there is another timeout ACK algorithm.
On the test I’ll give an example of getting the number of clients connected to the usual sectoral antenna Ubiquiti AirMax Rocket M5.
We will receive the data via SSH.
To test once we connect to the device (the first time when connecting, type yes and press enter):
sudo -u zabbix ssh -p 22 admin@192.168.0.55
Now in Zabbix we add the data element to the template or host, for example with the name “Template Ubiquiti Rocket M5 Sector”:
Name: any Type: SSH agent Key: ssh.run[clients,,22,utf8] Authentication method: Password Username: NAME Password: PASSWORD Executed script: the command executed on the device (see below)
Example of the command displayed the number of connected clients:
wstalist |grep "mac" |wc -l
Accordingly, we create a graph for the data element, as well as the trigger:
Name: On the sector antenna {HOST.NAME} > 40 clients Expression: {Template Ubiquiti Rocket M5 Sector:ssh.run[clients,,22,utff8].last(#1)}>40
See also:
Configuring SSH checks in Zabbix
I wrote a template for Ubiquiti PowerBeam 5AC for Zabbix and explored several basic SNMP OIDs for which you need to draw graphics.
OID tested for devices that are configured in Station mode and with firmware v7.1.4 (XC).
You can check the OID from a Linux command, for example:
snmpwalk -v 1 -c public 192.168.1.20 .1
First of all, I looked at what interfaces there are (if you add VLAN, etc. on the device, their number can be shifted):
snmpwalk -v 1 -c public 192.168.1.20 ifDescr
The next MIBs can read incoming and outgoing traffic (I have LAN eth0 under index 4, WLAN ath0 under 10), for example for LAN traffic:
ifInOctets.4 ifOutOctets.4
Average CPU usage per 1min / 5min / 15min:
1.3.6.1.4.1.10002.1.1.1.4.2.1.3.1 1.3.6.1.4.1.10002.1.1.1.4.2.1.3.2 1.3.6.1.4.1.10002.1.1.1.4.2.1.3.3
TX and RX AP in kilobytes can be found by the following OID:
1.3.6.1.4.1.41112.1.4.7.1.17.1.4.24.214 1.3.6.1.4.1.41112.1.4.7.1.18.1.4.24.214
OID noise can be found by:
1.3.6.1.4.1.41112.1.4.7.1.4.1.4.24.214
Signal strength: 1.3.6.1.4.1.41112.1.4.5.1.5.1
Frequency: 1.3.6.1.4.1.41112.1.4.1.1.4.1
SSID: 1.3.6.1.4.1.41112.1.4.5.1.2.1
Uptime: 1.3.6.1.2.1.1.3.0
Free memory: 1.3.6.1.4.1.10002.1.1.1.1.2.0
Total Memory: 1.3.6.1.4.1.10002.1.1.1.1.1.0
MAC address of the access point to which the device is connected: 1.3.6.1.4.1.41112.1.4.5.1.4.1
The IP address of the access point to which the device is connected: 1.3.6.1.4.1.41112.1.4.7.1.10.1.4.24.214.232.12.159
Antenna type: 1.3.6.1.4.1.41112.1.4.1.1.9.1
See also:
SNMP OID and MIB for interfaces
Suppose we need to limit the speed on the client antenna.
Accordingly, it is in the station mode and is connected to the access point.
For restriction, we go to the web-based antenna management interface, open the Network tab, change the Configuration Mode: to Advanced, which will bring more parameters that you can configure .
At the very bottom, click on Traffic Shaping, check the Enable checkbox and specify the desired speed limit for WLAN0 or LAN0.
For example, you need to limit the reception speed to 5Mb/s and send up to 512Kbps, for reliability, we’ll specify a limit for both network interfaces, where Ingress is specified for WLAN0 5120, and for LAN0 512, respectively, for Egress, vice versa, WLAN0 – 512, and LAN0 – 5120, burst is left unchanged, that is, 0.
To apply the changes click below Change and then above Apply, after which the antenna configuration will reboot.
On the access point, alas, you can not limit the speed for each client, if you do the above settings (in reverse order), then the overall speed for all clients will be limited. In this case, you can cut the speed, for example billing, by turning on the Advanced tab Client Isolation in the Advanced tab so that clients do not see each other on the network and do not exchange traffic.
Done.