The setup is a UDM SE, with the modem at the main house, Using a wave pico to the wave micro down field to a location that can see all other out buildings within the 90 degrees.

I had updated all devices to 4.1.2, and downgraded them to 4.1.1 because I used these radios with success about 2 months ago at a festival. I am using all the supplied POE Bricks that came with the devices, although i did try to power 2 with a 24 volt passive port on a USW 8-150. Same results. I swapped the main pico feeding the micro, using the proper POE Brick, and I swapped out the Micro to a different one, using the supplied POE Brick. All were purchased in December 2024

Any Help would be appreciated.

I know it is possible to enquire about the port index assignment and then interrogate but that uses more management traffic.

Bill.

I'm pretty sure I've seen this with previous firmware versions. We have a link at 4.4 miles. When the 5GHz is in a DFS Wait and the 6GHz is connected, we actually have more capacity, sitting around 3Gbps. When the DFS wait is over, we drop to around 1.8Gbps.

@UI-Team Is this a bug?

We’ve seen 5 GHz backup disconnections on a few radios. This post documents one affected site with a working comparison station and logs from both ends. The 60 GHz link works, but the enabled 5 GHz backup cannot establish a stable usable connection. Replacing the affected CPE and updating it to match the AP’s firmware did not fix it.

All device names and network identifiers below are aliases. Observations were collected on October 26, 2026.

Topology and settings

• AP-A: original Wave-AP, 4.1.2 (MGMP), US country setting, bridge mode.

• CPE-A, affected: Wave-LR, now 4.1.2 (GMC), approximately 2.79 km from AP-A. Previously 4.1.1.

• CPE-B, working control: Wave-LR, 4.1.2 (GMC), approximately 1.99 km from the same AP.

• 5 GHz backup: 5840 MHz / 20 MHz; enabled on the affected station.

• Affected 60 GHz link: 69120 MHz / 1080 MHz, approximately −63/−62 dBm. It had about three days of uninterrupted connection before the firmware-update reboot and reconnected normally afterward.

What we have already done

• Replaced the affected station because we suspected its 5 GHz radio. The replacement has the same failure at the same location.

• Updated CPE-A from 4.1.1 to 4.1.2 and rebooted it. This removed the original firmware-version mismatch, but the backup still fails.

• Compared the displayed wireless keys on AP-A and CPE-A: they match. The AP’s MAC ACL is disabled. These are UI checks, not verification of every generated runtime setting.

• Checked CPE-B on the same AP, backup frequency and width. Its 5 GHz connection showed approximately 3 days 14 hours of uptime and balanced receive chains.

• Ran one 5 GHz site survey at CPE-A. It detected the intended AP at approximately −65 dBm on 5840 MHz / 20 MHz. The primary 60 GHz link stayed up.

Earlier AP-side pattern

Before CPE-A’s update, AP-A’s ath0 log repeatedly recorded authentication attempts. Four attempts reached association, then local deauthentication about 8–9 seconds later. Representative excerpt:

Oct 25 22:25:13 [AP-A] daemon.info hostapd: ath0: STA [CPE-A-MAC] IEEE 802.11: associated (aid 2)
Oct 25 22:25:21 [AP-A] daemon.info hostapd: ath0: STA [CPE-A-MAC] IEEE 802.11: deauthenticated due to local deauth request

The other association → deauthentication pairs were October 25 at 00:05:32 → 00:05:41 and 20:01:14 → 20:01:22, and October 26 at 00:52:28 → 00:52:36. Times are device-displayed MDT (UTC−06:00).

We found no “WPA: pairwise key handshake completed” entry for CPE-A on ath0 in that sample. CPE-B has successful 5 GHz pairwise and subsequent group-key completion; CPE-A’s primary wlan0 also completes its WPA exchange.

After the station update to 4.1.2

CPE-A now repeatedly reports an association rejection:

Oct 26 17:07:20 [CPE-A] daemon.notice wpa_supplicant[378]: ath0: Trying to associate with [AP-A-MAC] (SSID='[LINK-A]' freq=5840 MHz)
Oct 26 17:07:22 [CPE-A] daemon.notice wpa_supplicant[378]: ath0: CTRL-EVENT-ASSOC-REJECT bssid=[AP-A-MAC] status_code=1
Oct 26 17:07:24 [CPE-A] user.info autoacl[372]: Forcing DISCONNECT+REASSOCIATE on interface ath0 to sync BSSID (was: , now: [AP-A-MAC])
Oct 26 17:07:24 [CPE-A] daemon.notice wpa_supplicant[378]: ath0: CTRL-EVENT-SSID-TEMP-DISABLED id=0 ssid="[LINK-A]" auth_failures=1 duration=10 reason=CONN_FAILED

Further status-1 rejections occurred at 17:07:55 and 17:08:32, with CONN_FAILED retry backoff. AP-A recorded CPE-A authentication on ath0 at 17:07:21, without a successful association in that fresh sample. The primary had rejoined at 17:06:54.

The station also logs these startup messages:

nl80211: kernel reports: Unsupported attribute
nl80211: Set scan default IEs failed: ret=-22 (Invalid argument)

We are including those messages for context, not assuming they caused the failure. Startup lines dated October 19 precede clock synchronization and should not be treated as the actual incident date.

Request for Wave engineering

1. On MGMP/GMC 4.1.2, how do we distinguish an explicit AP association-response rejection from a local driver connection failure or timeout behind status_code=1?

2. Which AP and station debug logs, counters or packet-capture procedure should we use for one synchronized connection attempt? We want the actual association status/reason and, if association completes, the EAPOL exchange.

3. Could per-station AP state, autoacl/BSSID synchronization or generated runtime configuration explain this despite matching displayed keys and a disabled AP MAC ACL?

4. Are the scan-default-IE warnings expected on this hardware, and is there a known firmware issue matching this pattern? If so, which build should we test?

We understand that an already-connected healthy station does not prove every new association works, and that hearing a beacon does not verify the bidirectional RF path. We have not yet forced the healthy backup to rejoin, changed the channel/width, or rebooted/replaced the AP as controlled tests. We would appreciate the most useful capture before making those changes.

We are not claiming a confirmed firmware, hardware or RF root cause. Sanitized excerpts are included above; please advise which complete support/debug captures to supply through the thread’s Private files area for Ubiquiti employees.

Thank you,
Dustin — Aerux Broadband

In our graph you can see the modulation was zero before a config change, ran for 24 hours, then drops to zero again.

2.8.1 rc1....sup files attached @UI-Team

Thx.

Must haves

• 5mhz channel selection increments - Currently having channel selections forced to the standard wifi channels is extremely limiting and makes upgrading from AirmaxAC or AirFiber5xHD an issue as I cannot match channel coverage and also lose some channels.
• Manual alternate frequency list when choosing a DFS channel

Strong wants

• Fixed ratio TDD/GPS sync
• SNMP

Also, I still have a feeling that Wave MLO is really just regular Wifi7 as I have seen nothing about how it operates or how it performs to tell me otherwise. That would be why they still do standard wifi channels selections, and why there is no TDD or GPS sync. Maybe UI was counting on the 802.11be standard to have enough to make it a viable outdoor PtP product without them having to do too much the MAC layer and that is why it still has major issues outside of a few circumstances.

I am started designing a PTMP for adding cameras but projections are incorrect because the old silo's still show as existing on the satellite view and provides incorrect projections.

We are experiencing a critical stability issue with our Wave network infrastructure. Out of approximately 50 installed Wave CPEs (predominantly Wave Nanos), around 20 units are randomly freezing.

Symptoms:

• The devices appear to remain wirelessly associated with the AP (the link stays up).
• Absolutely no data passes through the connection.
• The issue persists indefinitely until a physical restart (hard power cycle) of the affected CPE is performed.

I have configured a ping watchdog to monitor the drops and have attached the relevant export/support file privately to this thread for your review.

Could you please check the attached logs and advise on a potential fix, or let me know if further debugging is required?

Thank you, Richard

Set to 160MHz for both 5GHz and 6GHz. Using 2.8.1-rc1, having a bug of antenna settings stuck, so power isn't exactly where I want/need it to be.

Randomly, after either 10 minutes or 10 hours or 2 days, one of my AP's will randomly restart itself. To rule out the obvious, I've tried:

• Different power supplies (Hyconext switch, 51V @ 4pair; stock 30W POE injector; 4-pair 80W UI injector)
• Different firmware (4.1.0, 4.1.1, back to 4.1.0)
• Different frequencies for both 5GHz and 60GHz, and dropping 5GHz TX power
• Different physical radio (replaced existing AP with brand-new one, no difference)

The radio has sent a couple of reports on its own. @UI-Team should hopefully be able to pick them out using this support file.

The only thing I can imagine is that there's a customer with a weak 60GHz link (for some reason; need to check alignment). She switches between 60GHz and 5GHz. But it shouldn't cause a radio reboot, especially during fade events (rain/snow). None of the other 7 nearby AP's and PTP's are doing it.

Does anyone have the Wave MLO6 radios operating as a true wireless bridge that is working with MSTP or even just STP and Tagged VLANs?

I have tried all of the recent versions up to and including 2.8.1-rc1.

All the new versions seem to address GUI fixes or AFC issues but nothing said about all of the problem with STP and VLANs.

I have been struggling with this for months now and UI will not even acknowledge the problem.

It would be nice to hear that they are aware of the problems and are working on it.

The lack of communication on this is disheartening.

I can't imagine how much more these would sell if they really were a true wireless bridge.

We really need something 6 Ghz that can backup our Wave 60 Ghz links that can use spanning tree.

Saturday morning Cambium collapsed. They ran out of cash (per multiple reports of now former employees). There's strong rumors that PMP has been purchased by Airspan. No credible rumors on EPMP being sold but some less-than-confirmed hints at it. The vast majority of staff was let go, multiple divisions appear to have been 100% cut. I believe cnMaestro has lost 100% of staff. cnHeat 100%. Apparently every single European employee gone.

I'm posting here to ask Ubiquiti to save the industry. It's been some rough years for sure, but I believe the wISP industry is on the verge of complete collapse. There are few capable players in the game to pick up the slack from Cambium. If Ubiquiti or Robert still holds any love for the industry, I'd ask that you literally 'step in' and save it. I realize that there are higher margins in other products, but there's a bunch of real tallent that's on the market that could be scooped up for MLO and there are profits here, expanding and utilizing that tallent that's now looking for work and so not pulling resources of 'unifi' would be an absolute gift to the wISP industry and buy a mountain of good will.

i do see some carrier stuff in fabrics, and while I've been very concerned about ubiquiti just leaving the wISP industry entirely, this gives me hope.

I know UI keeps things close to chest, but please make one exception and let us know if Ubiquiti is committed to wISP. Ubiquiti very well may hold an entire industry in the US and many other countries in it's hands right now.

Thank you.

Attachments:

• MGMP_0cea14787d11_260905-184753.sup

The installation manual online shows a precision mount option, which looks to be the standard precision mount with an adapter for the Nano. Does this exist? It would be nice to have an alternative to the tedious mount that comes with the Nano.

I have two wireless bridges set up with 2 Wave Pro and 2 MLO 6 radios.

A switch on both sides with 2 ports setup as bonding with active backup.

Ive done a lot of searching in the community, doing a lot of reading but i'm not sure if anyone actually has this working.

• I'm currently running version 4.1.0 on both Wave Pro radios and carrier drop doesn't seem to be working in my tests. It on drops the sfp+ port on the station side and not on the main side. I noticed in the bugfixes release notes of 4.1.0 states this was fixed. Wave Pro: Fixed carrier drop not disabling the SFP+ port.

I have also tested this with 4.1.1 and the lastest beta but it never turns off the sfp+ port on the main side of the link hence the backup never works.

If someone has this working please let me know. Much apprectiated.