Both devices have the same CPU (Atheros AR934x) and SYSID (0xe7f9), but behave differently when downgrading firmware.

Device 1 – downgrade successful

• MAC prefix: 78

• BOM: 13-00497-14

• board.required_fw_version: 524800

• Downgrade: 8.7.4 → 8.7.0 → 8.6.2 → 8.5.12

Device 2 – downgrade rejected

• MAC prefix: F4

• BOM: 13-00497-29

• board.required_fw_version: 526084

• Firmware 8.7.1 rejected with a minimum firmware version error.

I also tested a beta firmware on the second device, but it resulted in initialization error A12.

Both devices have the same model, CPU and flash partition layout.

My question: Does the newer BOM revision (13-00497-29) have a firmware downgrade restriction requiring airOS 8.7.4 or newer?

Has anyone experienced the same behaviour?

Thanks!

I decided to replace both of them, and when evaluating which new devices to purchase, I ruled out the 5 GHz models because the link is NLOS and 2.4 GHz devices are more suitable.

I ruled out the NanoStation M2, M2 Loco, and PowerBeam M2 400 because it appears they are in a maintenance-only phase and limited to airOS 6.

I narrowed my search down to the NanoBeam 2AC and PowerBeam 2AC 400 devices, ruling out the latter even though it offers better performance: the antenna’s diameter and weight of nearly 2 kg would force me to replace the current poles.

The choice therefore comes down to the NanoBeam 2AC: is there a product better suited for my use case ?

I would need default network and VLAN 2 at the shop, so I can use a Unifi U7 Lite.

I would need VLAN 3 at the barn for a camera, hooked up to a PoE block, but otherwise directly to the airMAX device.

Assuming default = 192.168.1.1, VLAN 1 = 192.168.10.1, VLAN 2 = 192.168.20.1, and VLAN 3 = 192.168.30.1

I am familiar with Unifi so I don't need any help there, just with the airMAX setup.

PS - drawing not to scale

Can anyone give me directions on how to set this up, please?

Configured them (had two Nanostation 5AC Loco's before) and set them up. They are about 10 feet high with good line of sight. The problem is I can only get about 130 mbps with around a -52 to -58 signal. And the signal chain difference on one end is above 10. On the other is always less than 4., and it has 8X rate. The Station Nano was the one with less performance. I have lined and relined it to the best I can get it.

So a couple days ago I figured I would reset them to factory settings and reconfigure and see it there was a change. BUT....I changed them around and set up what was the station as the AP and the AP as the station. Guess what? It's the exact same thing with the same Nanobeam being the weak one.

So my question is this: Is there a chance that something is wrong with the one that only gets 4X and high chain difference? Just curious if I need to replace it.

Thanks for anything you can add.

Log shows: "Received deauth from AP. Reason: Disassociated due to inactivity (4)", then it reconnects straight away.

Restarting the NanoBeam fixes it for 3-4 hours, then it comes back. I haven't changed any settings.

Device Model NBE-5AC-Gen2

Firmware Version WA.v8.7.25

Can you check the AP side (my uplink signal, interference/DFS on Ch 60, and AP load)?

Thanks.

0.ubnt.pool.ntp.org'
Oct 27 12:24:39 wireless: ath0     Received deauth from 28:70:4e:b8:7b:bd. Reason: Disassociated due to inactivity (4).
Oct 27 12:24:39 wireless: ath0     Deauthenticated from AP 28:70:4e:b8:7b:bd (Disassociated due to inactivity)
Oct 27 12:24:39 wireless: ath0     New Access Point/Cell address:Not-Associated
Oct 27 12:24:39 wireless: ath0     Scan request completed
Oct 27 12:24:39 wireless: ath0     Set Mode:Managed
Oct 27 12:24:39 wireless: ath0     Set Frequency:5.3 GHz (Channel 60)
Oct 27 12:24:39 wireless: ath0     Sending auth to 28:70:4e:b8:7b:bd. Status: Successful (0).
Oct 27 12:24:39 wireless: ath0     Received auth from 28:70:4e:b8:7b:bd. Status: Successful (0).
Oct 27 12:24:39 wireless: ath0     Sending assoc_req to 28:70:4e:b8:7b:bd.
Oct 27 12:24:39 wireless: ath0     Received assoc_resp from 28:70:4e:b8:7b:bd. Status: Successful (0).
Oct 27 12:24:39 wireless: ath0     New Access Point/Cell address:28:70:4E:B8:7B:BD
Oct 27 12:24:39 init: process '/sbin/ntpclient -n -s -c 0 -l -h 0.ubnt.pool.ntp.org' (pid 10441) exited. Scheduling for restart.
Oct 27 12:24:39 init: Run: /sbin/ntpclient -n -s -c 0 -l -h 0.ubnt.pool.ntp.org
Oct 27 12:24:39 init: starting pid 18790, tty '/dev/null': '/sbin/ntpclient -n -s -c 0 -l -h 0.ubnt.pool.ntp.org'
Oct 27 12:25:09 wireless: ath0     Received deauth from 28:70:4e:b8:7b:bd. Reason: Disassociated due to inactivity (4).
Oct 27 12:25:09 wireless: ath0     Deauthenticated from AP 28:70:4e:b8:7b:bd (Disassociated due to inactivity)
Oct 27 12:25:09 wireless: ath0     New Access Point/Cell address:Not-Associated
Oct 27 12:25:09 wireless: ath0     Scan request completed
Oct 27 12:25:09 wireless: ath0     Set Mode:Managed
Oct 27 12:25:09 wireless: ath0     Set Frequency:5.3 GHz (Channel 60)
Oct 27 12:25:09 wireless: ath0     Sending auth to 28:70:4e:b8:7b:bd. Status: Successful (0).
Oct 27 12:25:09 wireless: ath0     Received auth from 28:70:4e:b8:7b:bd. Status: Successful (0).
Oct 27 12:25:09 wireless: ath0     Sending assoc_req to 28:70:4e:b8:7b:bd.
Oct 27 12:25:09 wireless: ath0     Received assoc_resp from 28:70:4e:b8:7b:bd. Status: Successful (0).
Oct 27 12:25:09 wireless: ath0     New Access Point/Cell address:28:70:4E:B8:7B:BD
Oct 27 12:25:09 init: process '/sbin/ntpclient -n -s -c 0 -l -h 0.ubnt.pool.ntp.org' (pid 18790) exited. Scheduling for restart.
Oct 27 12:25:09 init: Run: /sbin/ntpclient -n -s -c 0 -l -h 0.ubnt.pool.ntp.org
Oct 27 12:25:09 init: starting pid 18851, tty '/dev/null': '/sbin/ntpclient -n -s -c 0 -l -h 0.ubnt.pool.ntp.org'
Oct 27 12:25:47 wireless: ath0     Received deauth from 28:70:4e:b8:7b:bd. Reason: Disassociated due to inactivity (4).
Oct 27 12:25:47 wireless: ath0     Deauthenticated from AP 28:70:4e:b8:7b:bd (Disassociated due to inactivity)
Oct 27 12:25:47 wireless: ath0     New Access Point/Cell address:Not-Associated
Oct 27 12:25:47 wireless: ath0     Scan request completed
Oct 27 12:25:47 wireless: ath0     Set Mode:Managed
Oct 27 12:25:47 wireless: ath0     Set Frequency:5.3 GHz (Channel 60)
Oct 27 12:25:47 wireless: ath0     Sending auth to 28:70:4e:b8:7b:bd. Status: Successful (0).
Oct 27 12:25:47 wireless: ath0     Received auth from 28:70:4e:b8:7b:bd. Status: Successful (0).
Oct 27 12:25:47 wireless: ath0     Sending assoc_req to 28:70:4e:b8:7b:bd.
Oct 27 12:25:47 wireless: ath0     Received assoc_resp from 28:70:4e:b8:7b:bd. Status: Successful (0).
Oct 27 12:25:47 wireless: ath0     New Access Point/Cell address:28:70:4E:B8:7B:BD
Oct 27 12:25:48 init: process '/sbin/ntpclient -n -s -c 0 -l -h 0.ubnt.pool.ntp.org' (pid 18851) exited. Scheduling for restart.
Oct 27 12:25:48 init: Run: /sbin/ntpclient -n -s -c 0 -l -h 0.ubnt.pool.ntp.org
Oct 27 12:25:48 init: starting pid 18928, tty '/dev/null': '/sbin/ntpclient -n -s -c 0 -l -h 0.ubnt.pool.ntp.org'

We operate airMAX stations in bridge mode (Station WDS) behind an upstream relay that needs DHCP Option 82 to identify each subscriber. The built-in DHCP relay (/bin/dhcp-fwd) does not work reliably in this setup. So we wrote a replacement and implemented it far enough that it could replace the current dhcp-fwd on the device as it is. It runs today on a live customer station (PowerBeam 5AC, WA.v8.7.11) and is started by airOS init through the normal "DHCP Relay" switch in the web UI.

We would be very glad if Ubiquiti reviewed the code and shipped it, or something based on it, in one of the next firmware releases.

Repository: https://github.com/RcRaCk2k/ubiquiti-airmax-dhcp-fwd-alternative

The code is MIT licensed, our own and written from scratch (no code from the existing dhcp-fwd).

The problem

The current dhcp-fwd is based on dhcp-forwarder 0.10 and is a classic Layer 3 relay. On a transparent bridge this causes several problems:

1. It needs an IP address on every interface. It receives on a UDP socket bound to the bridge and expects IPv4 on each configured interface. Bridge ports such as eth0 or ath0.1284 have no address on a station. If you configure them anyway, DISCOVERs stop working completely and the subscriber goes offline. We have had this happen.

2. Unicast renews get no Option 82. A relay only sees broadcasts. Renews and rebinds are sent by unicast to the server or the router MAC, so they pass through the bridge unmodified. The DHCP server then sees Option 82 on DISCOVER/REQUEST but not on RENEW. That makes consistent subscriber identification impossible.

3. It sets giaddr and increments hops. In our network the upstream relay has to put its own public address into giaddr. A station that sets giaddr itself breaks that.

4. There is no DHCP snooping on the station. It is handled by separate firewall rules, and "Apply" regenerates or replaces those rules.

5. Broadcasts can be processed twice. We see every broadcast return from the AP side about 7 ms after it was sent. A socket bound to the bridge probably sees that echo as well.

How we solved it

The replacement is a transparent Layer 2 agent instead of a relay:

• Packets are taken out of the bridge with ebtables broute. Our own chain (DHCP_SNOOPING_82, policy RETURN, jump at position 1) diverts DHCP requests from customer ports and server replies from uplink ports. The agent receives them on AF_PACKET sockets bound to each bridge port, with classic BPF filters, and sends them out directly on the opposite port. It never sends on the bridge itself.

• No duplicates are possible, by design. On kernel 2.6.32, a protocol handler only receives a bridged frame if the bridge hook hands it back, which happens on broute DROP. If the rules are missing, the agent receives nothing and the bridge forwards the original exactly once. If the agent is stopped while its rules are still in place, nothing goes out without Option 82 (fail-closed).

• Option 82 is inserted exactly once, also into unicast renews and rebinds. It goes into the PAD area after the END option; the packet grows only if that is not enough, and never beyond the MTU. IP/UDP lengths and checksums are recalculated. giaddr, hops, flags, MAC and IP addresses stay untouched.

• Existing Option 82 is never overwritten. If a request already carries Option 82, giaddr or hops, it is forwarded unchanged.

• Replies are cleaned up and delivered to the right port. Our own Option 82 is removed from replies, which then go only to the customer port the circuit ID belongs to. Replies carrying someone else's Option 82 are dropped. Replies without Option 82 go to the port the request came from, matched by transaction ID (xid).

• DHCP snooping is built in. DHCP servers on a customer port are blocked, and so are requests from other subscribers arriving from the uplink. The separate firewall rules for this are no longer needed.

• IDs: circuit ID <hostname>/<bridge>:<port>, e.g. station-01/br1:eth0; remote ID = bridge MAC as hex text. Both are templates and can be changed.

• Robustness: the binary is static (MIPS32r2 big-endian, about 140 KB), runs as a root watcher plus an unprivileged packet worker (uid 99), logs to syslog in RAM only, and puts its rules back within 5 seconds after "Apply" flushes ebtables.

• Drop-in replacement: the binary is still called dhcp-fwd and accepts the existing command line /bin/dhcp-fwd -n -c /etc/dhcp-fwd.conf, so the existing inittab entry and the web UI switch keep working without changes.

Tests: unit tests with fuzzing and sanitizers, a full bridge simulation in network namespaces (lease cycle, foreign Option 82, rogue server, fail-closed, no duplicates, several customer ports, VLAN uplinks), and the live station. In the live test the upstream relay received each request exactly once, kept our sub-options 1 and 2, and the subscriber got its lease on the first attempt.

Trusted and untrusted ports: auto-config today, UI later

Today the agent configures itself. It uses every bridge that has the DHCP relay enabled in /tmp/system.cfg, and classifies each bridge member by the physical interface below any VLAN:

• ath* (wireless, upstream) → trusted

• eth* (customer side) → untrusted

This covers eth0, eth0.100, ath0, ath0.1284 and stations with several Ethernet ports, without any configuration. Other members such as gre0 are left alone.

With some additional changes to the airOS UI, users could define the trusted and untrusted ports themselves, e.g. a Trusted/Untrus the DHCP relay settings. The UI would then simply start the agent with explicit ports, which turns the auto-config off:

dhcp-fwd -n -u br1:eth0 -t br1:ath0.1284

dhcp-fwd -n -u br1:eth0,br1:eth1 -t br1:ath0 -i '%h/%b:%p' -r '%m'

-u = untrusted (customer port), -t = trusted (uplink), -i/-r = circuit ID and remote ID templates. -o section.key=value can set any other option, e.g. turning snooping off. Without these parameters the auto-config stays active, so existing installations keep working unchanged.

What a firmware integration would ideally add

• Create the broute rules in the airOS ebtables setup, so they survive "Apply" without being re-added.

• Optionally keep the existing FORWARD … --ip-dport 67 DROP rule as an extra fail-closed safeguard; it does not interfere with the

• Add the trusted/untrusted selection to the UI described above.

The code is plain C with no external dependencies apart from ebtables and should build with Ubiquiti's own toolchain. We are happy to answer questions, adapt the code to your requirements, or test beta firmware on our stations.

Thank you for considering it!

Related Topics:

• MikroTik forum: DHCP Option 82 with Ubiquiti Radios (https://forum.mikrotik.com/viewtopic.php?t=148922)

• Splynx forum: DHCP option 82 with Radius (https://forum.splynx.com/t/dhcp-option-82-with-radius/1161)

• UI Community: DHCP relay and Option 82? (https://community.ui.com/questions/e6eeb13d-bf4f-40bc-b1de-3da3ab06aba6)

• UI Community: DHCP Option 82 (https://community.ui.com/questions/e020d17e-eb6a-4a59-b0d0-2e11da238347)

• UI Community: Using Option 82 (https://community.ui.com/questions/Using-Option-82/b24c06ee-774b-49c4-8d74-6a86d09890cf)

• UI Community: DHCP Option 82 Configuration (https://community.ui.com/questions/DHCP-Option-82-Configuration/5414b10f-e44f-4dcd-ae9f-a24f715f634c)

• UI Community: Extending DHCP Option 82 Functionality (https://community.ubnt.com/t5/airOS-Software-Configuration/Extending-DHCP-Option-82-Functionality/td-p/2545014)

• TechSupportForum: DHCP Broadcast Storm (https://www.techsupportforum.com/threads/solved-dhcp-broadcast-storm.703414/)

• airOS 8.5.8 changelog (https://dl.ubnt.com/firmwares/XC-fw/v8.5.8/changelog.txt)

I have a pair of PowerBeam 5AC Gen2 units running on the latest firmware. It only works on 10 mbps and they have been in service for 2 years without any issues. Suddenly, the receiver side is no longer negotiating 1000/100 Mbps (link drops to 10 Mbps).

Troubleshooting steps already taken:

1. Replaced the PoE adapter of receiver side with a new one – no change.

2. Replaced all Ethernet cables of receiver side with new ones – no change.

3. Replaced the receiver-side PowerBeam 5AC Gen2 with a brand-new unit – no change.

4. Replaced The switch on receiver-side with a brand-new - no change

Additional notes:

• The Ethernet cable run from the PoE injector to the dish is 98 meters (321 ft). This length has been in use for the entire 2-year period while the link was running at 1000 Mbps, so I don't believe the cable length itself is the root cause.

• My mode is bridge mode not a router

• it only works on 10mbps which is pretty slow

Any guidance on what else I should check would be greatly appreciated.

Thanks.

I will post pictures of the dashboards ASAP.

I use Auto in the field, and switching radios back to it has resolved a number of issues. Could Ubiquiti either add Auto back as a selectable Center Frequency option after manually selecting a frequency, or confirm whether there is still a technical reason it needs to remain unavailable? Since the function is still present and can be restored through the CLI, it would be helpful to understand whether there is a known issue or limitation keeping it out of the GUI on airOS 8.

In my employer's deployment model, radios are configured at one location and then installed at a different site where the RF environment is not known during staging. Auto allows us to preconfigure the radios, install them in the field, and bring the link up without having to stop and manually select a Center Frequency at each location. A fixed frequency chosen during staging may not be appropriate at the install site, which is why being able to return the radio to Auto is important for our workflow.

@UI-Team, could you confirm whether there is still a technical reason Auto must remain unavailable in the GUI after manually selecting a Center Frequency, or whether this can be restored in a future airOS 8 release?

airMAX AC 8.6.1 | Aug 8, 2019: “Removed ‘Auto’ from Center Frequency list - pending improvements in subsequent releases”

SSH into CLI: ssh <username>@<radio-IP>

Purpose: Restore Auto Center Frequency without factory reset or uploading configs.

Conclusion: On the devices tested, Auto is represented by:

radio.1.freq=0

radio.1.center.1.freq=0

Restoring those values returns Center Frequency to Auto while preserving the rest of the device configuration.

Confirmed and tested on: airMAX LiteBeam 5AC (LBE-5AC-Gen2) and airMAX IsoStation 5AC (IS-5AC)

Useful References:

Ubiquiti 8.6.1 Official Release Notes

Unable to select AUTO after choosing a specific frequency

LAP-GPS Auto Center Frequency issue

PowerBeam AC Gen2 will not go back to Auto Channel

UI-Team guidance on changing frequency through SSH

**1. Check whether Center Frequency is set to Auto

grep -E '^radio\.1\.(freq|center\.1\.freq|chanbw)' /tmp/system.cfg

Expected result when Center Frequency is Auto:

radio.1.freq=0

radio.1.chanbw=40

radio.1.center.1.freq=0

The important values are:

radio.1.freq=0

radio.1.center.1.freq=0

chanbw may vary depending on the configured channel width.

**2. Check after manually selecting a Center Frequency

grep -E '^radio\.1\.(freq|center\.1\.freq|chanbw)' /tmp/system.cfg

Example result:

radio.1.freq=5200

radio.1.chanbw=40

radio.1.center.1.freq=5210

The exact frequency values depend on the Center Frequency selected.

**3. Restore Center Frequency to Auto

sed -i 's/^radio\.1\.freq=.*/radio.1.freq=0/' /tmp/system.cfg

sed -i 's/^radio\.1\.center\.1\.freq=.*/radio.1.center.1.freq=0/' /tmp/system.cfg

This changes only the two frequency values back to the internal Auto value of 0.

**4. Verify Auto was restored

REPEAT STEP **1

At this point, refresh the airOS 8 GUI and confirm Center Frequency displays Auto again.

**5. Write the edited airOS 8 configuration to persistent flash storage.

cfgmtd -f /tmp/system.cfg -w

You may see outputs similar to:

Found Backup1 ...

Found Active ...

Storing Active ... [100%]

Active->Backup ... [100%]

Exact wording can vary by firmware/platform.

This step is important because /tmp/system.cfg is the working configuration file in RAM. The cfgmtd -f /tmp/system.cfg -w command writes that edited configuration to the radio’s persistent flash storage so the changes survive a reboot.

**6. Verify the saved values

grep -E '^radio\.1\.(freq|center\.1\.freq|chanbw)' /tmp/system.cfg

Expected:

radio.1.freq=0

radio.1.chanbw=40

radio.1.center.1.freq=0

For a full proof test, reboot:

reboot

Then reconnect and run the same grep command. If the two frequency values are still 0 and the GUI shows Auto, you've demonstrated that the workaround is persistent.

Everything look ok? They are pretty close, maybe 60 feet away from each other just to get internet to the other side of the road. I have a airplay2 stream that traverses this and sometimes it cuts out, we're trying to figure out if it's related to the bridge.

We have a HomePod on the TX side that initiated an airplay2 stream to a speaker on the RX side. RX side is connected to a flex switch and passes through a U7 outdoor pro to get to the speaker.

I have two AF-24 which are sitting right beside one, for some reason they wont connect and they are showing this weird signal strenght, what appears out of nowhere. Is radio just broken?

These are screenshots of setup and dashboard

I would be grateful for any help

I would like to request more detailed historical wireless statistics for airMAX devices in UISP, particularly some of the data that used to be available in earlier UNMS/UISP versions.

At the moment, UISP gives us useful historical graphs for overall signal strength, capacity, link potential, throughput, etc., but important RF parameters such as individual chain signal levels / chain difference and modulation changes appear to be available only as live values.

It would be extremely useful if UISP could historically log and graph at least:

• Signal strength for Chain 0 and Chain 1 separately
• Chain difference
• TX/RX modulation/MCS
• TX/RX data rate
• Noise floor
• CCQ / link quality where supported
• Ideally retransmissions/errors if available from the device

A real-world example of why this matters:

We operate several 5 GHz PtP link across a fjord in Norway, currently using a Rocket 5AC with a 34 dBi RocketDish at one end and a PowerBeam 5AC ISO at the other.

The links itself are excellent, normally around -60 to -64 dBm and running 256-QAM. However, because the path is almost entirely over seawater, we see very repeatable multipath effects caused by reflections from the sea surface.

We have compared the UISP signal history with measured sea-level data from the Norwegian Mapping Authority. We are seeing signal drops of approximately 5–6 dB at particular sea levels. Interestingly, the drops occur at approximately the same water level regardless of whether the tide is rising or falling.

This makes a very useful real-world RF experiment: changing sea level changes the path length of the reflected signal relative to the direct path, producing constructive/destructive interference.

The problem is that UISP only lets us see the resulting overall signal-strength change historically.

During these events, what we really want to know is:

What happened to each MIMO chain? Did the chain difference increase? Did modulation drop from 8X/256-QAM to 6X or lower? Did noise remain constant? Did capacity decrease because of modulation or because of interference?

All of those values are available from the radio in real time, but having to watch the device UI at exactly the right moment defeats much of the purpose of having a monitoring system such as UISP.

Historical per-chain and modulation data would also be extremely useful for diagnosing much more common problems: antenna alignment, damaged feeds/cables, water ingress, changing interference, polarization problems, fading and marginal long-distance links.

Even relatively low-resolution logging (for example one sample every 5 minutes) would be more than sufficient and would require very little storage.

Older UNMS/UISP versions also seem to have exposed more per-chain information in the statistics graphs. If these metrics are still collected internally, it would be great to have them exposed again in the current UISP interface.

For WISPs and anyone maintaining PtP/PtMP wireless infrastructure, I think these RF metrics are considerably more useful for troubleshooting than overall RSSI alone.

Please consider bringing detailed historical RF statistics back to UISP.

I have the following setup on a local network, totally isolated from the internet:

One NanoStation Loco M5 Firmware v5.6.11 (XW) working as main AcessPoint

2 Bullet M5 firmware v5.6.11 (XM) working as clients.

One of the bullets is working fine, however the other one is presenting a strange behaviour noticeable on the logs below, which appear once a day, even though no one is accessing it via web nor SSH (please ignore the duplicated timestamp as I cannot make the ntp client service work properly):

2026-09-17 09:56:30.515 10.10.50.150

<30>Sep 30 12:37:30 wireless: ath0 New Access Point/Cell address:78:8A:20:6E:EE:09

2026-09-17 09:56:30.515 10.10.50.150

<13>Sep 30 12:37:29 FileSystem: End check.

2026-09-17 09:56:30.515 10.10.50.150

<86>Sep 30 12:37:24 dropbear[987]: Not backgrounding

2026-09-17 09:56:30.508 10.10.50.150

<13>Sep 30 12:37:24 FileSystem: Start check...

2026-09-16 12:54:00.775 10.10.50.150

<30>Sep 30 12:37:30 wireless: ath0 New Access Point/Cell address:78:8A:20:6E:EE:09

2026-09-16 12:54:00.775 10.10.50.150

<13>Sep 30 12:37:29 FileSystem: End check.

2026-09-16 12:54:00.775 10.10.50.150

<86>Sep 30 12:37:24 dropbear[987]: Not backgrounding

2026-09-16 12:54:00.692 10.10.50.150

<13>Sep 30 12:37:24 FileSystem: Start check...

As you can see, this FileSystem check starts and ends, making the radio connect again to the AP. The bullets are used in a production environment, so they cannot lose connection that often. Does anyone know why this is happening? This device was brand new before we set it up.

Some more information:

Wirelles mode of the clients is Station, WDS is disabled on all of the 3 devices, DFS is enabled on the strange one, Frequency Scan List is disabled.

I'm having an issue with a point-to-point link using two LiteBeam M5 radios that I'd like to explain. Just a heads-up: I'm not a network expert; I've been working as a sysadmin for about 2 years in my first IT job, and I keep stumbling upon problems that I try to understand and solve.

At a client's site, we have two Ubiquiti LiteBeam M5 units connecting two buildings located less than 100m apart—basically facing each other across the street. The radio on Building A connects directly to one of the rack switches, providing connectivity to Building B. We monitor both radios with Uptime Kuma to check for outages. That’s precisely what’s happening now: every now and then, one of the radios drops connection for a few seconds. As a result, the buildings lose communication, with Building B being the most affected since it receives both Internet and local network access from Building A.

I’ve been investigating this issue with my limited knowledge but plenty of drive to understand how things work, partly helped by Gemini and partly by reading community posts. I checked a few settings first, such as the Output Power on both sides, which is currently set to 7 dBm on both radios. Gemini mentioned that this might still be too much power for such a short distance and could be causing link instability.

However, what really got me thinking and investigating further is the WDS (Transparent Bridge Mode) option. It's worth mentioning that the network is not segmented at all; there are no VLANs between the buildings, and virtually no VLANs in general. If I SSH into radios A and B and run brctl showmacs br0 to check the MAC address table learned by the bridge, I see a huge list of entries. Based on how the radios and the network are configured, I understand the following is happening:

1 - Packets from any device reach the radio because broadcast traffic isn't properly managed or constrained.

2 - Those packets move from the Ethernet interface (eth0) to the wireless interface. During this transit, the radio "masquerades" the original MAC address and replaces it with its own MAC to forward the packet to the other radio.

3 - This L2 masquerading consumes CPU cycles to receive, rewrite, and look up entries in the bridge control table.

4 - These radios have very limited CPU resources, so these continuous operations saturate the processor, eventually causing it to collapse and fail to process packets.

To monitor the radios more effectively, I set up a LXC container with rsyslog to collect system logs. I also installed a UISP container (Unifi-like controller for Ubiquiti radios) to track CPU and RAM usage accurately. I noticed a distinct "sawtooth" pattern in CPU usage, with spikes frequently hitting 80% to 90%.

I also ran a test to correlate what I was seeing in UISP. I captured multicast packets directly on the radio using tcpdump while simultaneously monitoring CPU usage with top. The tcpdump capture showed multicast packet bursts oscillating between 100 and 150 packets per second, and these peaks consistently matched the CPU spikes observed in both UISP and top. In top, I specifically noticed lines like this:

2026-09-15 09:28:49 CPU: 2% usr 2% sys 0% nic 40% idle 0% io 2%irq 50% sirq

2026-09-15 09:28:50 CPU: 3% usr 4% sys 0% nic 12% idle 0% io 4% irq 74% sirq

2026-09-15 09:28:51 CPU: 2% usr 2% sys 0% nic 26% idle 0% io 4% irq 63% sirq

The sirq values are consistently high. They rarely drop below 15% and frequently spike as shown above. If I understand correctly, these are Software IRQs related to network processing. Following up on this, I checked /proc/softirqs and /proc/interrupts by taking two snapshots about 8 hours apart. During that timeframe, the processor handled roughly 1,100 hardware interrupts per second and about 1,146 NET_RX SoftIRQs per second. I'm sharing these numbers while still learning these concepts, mainly to gather more technical data.

Beyond finding ways to mitigate broadcast traffic on the LAN, would enabling the WDS option help resolve this issue? My understanding is that with WDS enabled, the radio doesn't need to perform L2 MAC masquerading and packets travel directly as a "transparent bridge". Are these CPU consumption levels, hardware interrupts, and NET_RX SoftIRQ metrics expected behavior, or is something wrong here? That is, does this high interrupt load happen precisely because the radio's CPU can't keep up with constant L2 MAC rewriting?

I hope this makes sense, and apologies if I misstated any concepts—just trying to learn and figure this out! :)

I am advancing an 15 KM point to point solution for myself and a relative,

As the distance is, i am not able to see the endpoint as it is pretty far away,

Based on the UISP Design site, i can advance on how and where to place antennas and how to aim them in a general direction.

I will be placing an antenna on the roof of my house (10 Meters / 33FT in the air) and will do the same on the other side

As this is a test setup, and i dont want to inconvenience my relative with me coming over every so often to troubleshoot the link

I am looking for a good solution to get the link up first time, and keeping it online without me interfering with it.

It's more important getting stable traffic over the link (50mbit is enough) as long as the connection is stable and not flickering)

Would the Litebeam 5AC-LR work on this link? on both sides?

Again, a stable link is more important then mbits flying, we do not need gigabit speeds,

Money wise: a good stable link is important, but as it is a test setup, money is a factor, thats why a choosing the Litebeam 5AC-LR

if the link works, we will keep it and transform it from a test to a working setup (not mandatory but preferred)

I am looking for some advice,

Thank you..

Can anyone tell me what is the latest / best discovery tool to use?

I am about 10 years out of date with the info.

I still use the java tool on my windows 7 laptop and it works great - picks everything up no problem.

But we had a new staff member start and he is using a windows 10 laptop which I was told the old java tool wont work on it. He uses a different discovery tool (wifiman?) to find airmax devices.

But what we have found is it only discovers airmax devices if he has his ip address set to the same subnet as the device he is trying to find.

Is there a way around this so it will discover all devices on the layer 2 network?

The way it behaves makes me think its not using the same ubiquiti discovery protocol as the old java tool or the tool built into the airmax devices.

Im using rocket m5 and i dont know what happened i think its been struck by lightning i try basic troubleshoot such as using patch cords changing poe and so on but on computer it shows uplugged

Bare radio, gently and briefly used, no accessories

Free shipping in the US

Send a message