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.

Please find a way to make it either like Airmax or LTU or another way so that we can view only throughput in a real time graph without being cluttered by capacity.

Will it support AirMax CPEs?

Things i've tried:

1) Changed channels, still happens

2) Turned off 5ghz backup radio, still happens.

Jul 28 10:55:49 Adams to VanVleet daemon.info hostapd: wlan0: STA 0c:ea:14:78:78:eb IEEE 802.11: disassociated
Jul 28 10:55:51 Adams to VanVleet user.info autobridge_wireless[424]: br0: Added prs0 iface
Jul 28 10:55:51 Adams to VanVleet daemon.info hostapd: wlan0: STA 0c:ea:14:78:78:eb IEEE 802.11: associated
Jul 28 10:55:51 Adams to VanVleet daemon.info hostapd: wlan0: STA 0c:ea:14:78:78:eb RADIUS: starting accounting session 86E7E19C4B1A0D15
Jul 28 10:55:51 Adams to VanVleet daemon.info hostapd: wlan0: STA 0c:ea:14:78:78:eb WPA: pairwise key handshake completed (RSN)
Jul 28 10:55:52 Adams to VanVleet user.info wave_ai-wlan0[421]: Peer 0c:ea:14:78:78:eb disconnected with reason 34! Last sig: -56
Jul 28 10:55:52 Adams to VanVleet user.info wave_ai-wlan0[421]: Peer 0c:ea:14:78:78:eb re-connected after 46791 seconds!
Jul 28 12:56:06 Adams to VanVleet daemon.info hostapd: wlan0: STA 0c:ea:14:78:78:eb IEEE 802.11: disassociated
Jul 28 12:56:07 Adams to VanVleet user.info wave_ai-wlan0[421]: Peer 0c:ea:14:78:78:eb disconnected with reason 4! Last sig: -55
Jul 28 12:56:08 Adams to VanVleet user.info autobridge_wireless[424]: br0: Added prs0 iface
Jul 28 12:56:08 Adams to VanVleet daemon.info hostapd: wlan0: STA 0c:ea:14:78:78:eb IEEE 802.11: associated
Jul 28 12:56:08 Adams to VanVleet daemon.info hostapd: wlan0: STA 0c:ea:14:78:78:eb RADIUS: starting accounting session C5289ABF92D1F7E7
Jul 28 12:56:08 Adams to VanVleet daemon.info hostapd: wlan0: STA 0c:ea:14:78:78:eb WPA: pairwise key handshake completed (RSN)
Jul 28 12:56:10 Adams to VanVleet user.info wave_ai-wlan0[421]: Peer 0c:ea:14:78:78:eb re-connected after 3 seconds!
Jul 28 13:19:43 Adams to VanVleet daemon.info hostapd: wlan0: STA 0c:ea:14:78:78:eb IEEE 802.11: disassociated
Jul 28 13:19:45 Adams to VanVleet user.info autobridge_wireless[424]: br0: Added prs0 iface
Jul 28 13:19:45 Adams to VanVleet daemon.info hostapd: wlan0: STA 0c:ea:14:78:78:eb IEEE 802.11: associated
Jul 28 13:19:45 Adams to VanVleet daemon.info hostapd: wlan0: STA 0c:ea:14:78:78:eb RADIUS: starting accounting session 010E8C2A6E356960
Jul 28 13:19:45 Adams to VanVleet daemon.info hostapd: wlan0: STA 0c:ea:14:78:78:eb WPA: pairwise key handshake completed (RSN)
Jul 28 13:19:45 Adams to VanVleet user.info wave_ai-wlan0[421]: Peer 0c:ea:14:78:78:eb disconnected with reason 34! Last sig: -55
Jul 28 13:19:45 Adams to VanVleet user.info wave_ai-wlan0[421]: Peer 0c:ea:14:78:78:eb re-connected after 334507 seconds!
Jul 28 14:18:40 Adams to VanVleet daemon.info hostapd: wlan0: STA 0c:ea:14:78:78:eb IEEE 802.11: disassociated
Jul 28 14:18:40 Adams to VanVleet user.info wave_ai-wlan0[421]: Peer 0c:ea:14:78:78:eb disconnected with reason 34! Last sig: -56
Jul 28 14:18:43 Adams to VanVleet user.info autobridge_wireless[424]: br0: Added prs0 iface
Jul 28 14:18:43 Adams to VanVleet daemon.info hostapd: wlan0: STA 0c:ea:14:78:78:eb IEEE 802.11: associated
Jul 28 14:18:43 Adams to VanVleet daemon.info hostapd: wlan0: STA 0c:ea:14:78:78:eb RADIUS: starting accounting session 42964EDE1CDB3DE8
Jul 28 14:18:43 Adams to VanVleet daemon.info hostapd: wlan0: STA 0c:ea:14:78:78:eb WPA: pairwise key handshake completed (RSN)
Jul 28 14:18:43 Adams to VanVleet user.info wave_ai-wlan0[421]: Peer 0c:ea:14:78:78:eb re-connected after 3 seconds!

I noticed that in Version 4.1.0, for the Wave line, the Israeli regulatory requirements were updated under:

"Aligned main radio regulatory requirements for Israel"

However, it appears that the 2160 MHz channel bandwidth option was removed from the Israel regulatory profile for the Ubiquiti Wave products.

This appears to be incorrect according to the current regulations published by the Israeli Ministry of Communications.

The Israeli regulation for the 57–66 GHz frequency band explicitly allows operation using a 2160 MHz channel bandwidth, and this requirement has not changed since 2021.

According to the regulation:

Frequency range: 57–66 GHz

Approved channel center frequencies:

• 58.32 GHz
• 60.48 GHz
• 62.64 GHz
• 64.80 GHz

Maximum E.I.R.P: 40 dBm

Additional requirements:

• The wireless device must comply with ETSI EN 303 722
• The wireless device must operate using 2 to 4 channels with a bandwidth of 2160 MHz
• The wireless device must use WiGig technology
• The wireless device must include an active ATPC or ALA mechanism
• Intended usage: outdoor fixed PtMP links between fixed locations
• Intended usage: outdoor fixed PtP links between fixed locations

The regulation text has remained unchanged since 2021, so removing support for the 2160 MHz channel bandwidth from the Israel regulatory profile appears to be an incorrect restriction rather than an actual regulatory requirement.

Could you please review the Israel regulatory configuration for the Wave series and confirm whether this change was intentional?

If this was an accidental change, please consider restoring support for the 2160 MHz channel bandwidth in a future release.

Thank you for your assistance

@UI-Team