I cannot achieve a signal better than -82dbm or a throughput greater than 15 mbps.

I understand these aren’t designed for this short distance application but they are what I have on hand at this time.

Is this product incapable or producing a decent connection at this distance or am I missing something?

Thanks in advance for any help or input you can give!

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

I have a couple of NanoBeam M5s that won't connect to my UISP instance. My issue is exactly this one, as far as I can tell:

https://community.ui.com/questions/UNMS-Timed-out-waiting-SSL/a909f25d-426f-42d1-85be-eba5698a1cea

I get the same log messages, and I use a Let's Encrypt certified reverse proxy. I am not able to use a different reverse proxy, nor lower its security settings. I have a number of GigaBeam devices that connect just fine.

I'm on UISP 3.0.159, and the NanoBeams are currently on v6.3.24. (XW) The NanoBeam firmware is from December last year, so it feels like it should not be an issue of legacy implementations.

Well not fully a year later and it looks like the same thing happened again. Another lightning storm rolled through and the edgepower and edgeswtich 16 are down.

This sucks as I put those grounding boxes on the DC lines both at the top and bottom on the commercial cell tower grounded to the tower at the top and to the grounds at the bottom.

What the heck I am supposed to do as this is 3 Edgeswitch 16s in less than 2-3 years where before I survived many storms.

Do I need to contact Crown Castle and have them veriify the grounding of the tower itself?

What more can I do?

Has it ever been on the roadmap for Airmax APs to broadcast some sort of staging SSID to automate autoprovisioning for CPE antennas?

Life would be so much simpler if we could create a customer in UISP, assign the MAC of a Nano Loco (for example), and simply connect the CPE at the customer premises.

The CPE could scan for this staging network by default (probably hidden) through any AP it sees first. The AP would deny/allow the CPE to connect with its MAC via ACL. The CPE would then download its UISP config template (including all SSIDs availabe at all sites), self-provision itself with user-defined settings, hook to the strongest SSID of the company visible on site-survey, and then adopt itself to its assigned customer on UISP.

Something like this would enable installing new customers at light speed!.

First post for me in UISP. Regular UniFi user.

I have a UniFi network running within my home, I have an outer building, not to far from the house but not possible to run a cable without digging. My house has an outdoor AP AC Mesh on the back, full coverage.

Can I install 1 x airMAX NanoStation 5AC Loco on that building and connect it to my AP AC Mesh AP?

The airMAX NanoStation 5AC Loco will be connected to a USW 24 with only a couple of devices off it (1 camera, maybe an AP, possibly a superlink)

Thanks

Title: airOS 8 starts two competing BusyBox syslogd processes, preventing complete remote logging

 Product: LiteBeam 5AC

 Firmware: WA.ar934x.v8.7.11.46972.220614.0420

 BusyBox: v1.19.4

 Summary

 When both System Log and Remote Log are enabled, airOS may start two separate syslogd processes. The first local-only process appears to consume messages from the local logging socket, while

 the remote-capable process receives only a small subset. Consequently, logs visible through logread, including dnsmasq-dhcp events, are not forwarded to the configured remote syslog server.

 Configuration

 syslog.status=enabled

 syslog.remote.status=enabled

 syslog.remote.ip=<remote-syslog-server>

 syslog.remote.port=514

 Observed processes

 /bin/syslogd -n -S

 /bin/syslogd -n -S -L -R <remote-syslog-server>:514

 The local log contains normal application events such as:

 dnsmasq-dhcp: DHCPDISCOVER

 dnsmasq-dhcp: DHCPOFFER

 dnsmasq-dhcp: DHCPREQUEST

 dnsmasq-dhcp: DHCPACK

 dropbear: Password auth succeeded

 Most of these events do not reach the remote syslog server.

 Expected behavior

 A single process should provide both local and remote logging:

 /bin/syslogd -n -S -L -R <remote-syslog-server>:514

 BusyBox documents -L as logging locally as well as remotely when -R is used, so a second local-only daemon should not be necessary.

 Reproduction

 1. Enable System Log.

 2. Enable Remote Log and enter a remote server and UDP port 514.

 3. Save/apply the configuration.

 4. Inspect processes with:

 ps | grep syslog

 5. Confirm that two syslogd instances are running.

 6. Generate ordinary DHCP or SSH events.

 7. Compare logread with messages received by the remote server.

 Workaround observed

 1. Disable the main System Log service and apply.

 2. Both existing syslogd processes exit.

 3. Re-enable Remote Log and apply.

 4. airOS enables logging and starts one combined process:

 /bin/syslogd -n -S -L -R <remote-syslog-server>:514

 After this sequence, ordinary Dropbear messages were successfully received remotely.

 Persistence across reboot has not yet been confirmed.

 Suspected cause

 The boot/service startup path appears to start a local-only daemon first and then start a second remote-capable daemon without replacing the original process. Both attempt to consume the same

 local logging facility, and the first process receives most application messages.

 Requested correction

 Ensure that enabling local and remote logging starts exactly one combined syslogd process, and ensure service reloads terminate any obsolete instance before starting its replacement.

Same link after 5GHz is re-established

This is 2.8.0-RC1 with link direction enabled, 20 + 160 MHz, 2x5G34 dishes, many different channels and widths tested.

Is this a scheduling problem?

Performance starts out strong, then falls on its face after a few seconds. After a few minutes, customers are saying that they're "completely offline". Green lights on customer routers are turning orange or red.

By this point, customers were reporting being "completely offline".

I wasn't there to get a screenshot, but throughput dropped around 300 soon after.

This is a rain-fade backup, 4.2 miles, from a UISP-Dish master to a RD-5G34 slave. 20MHz + 160MHz using link direction so that upload has a solid sustained 100-ish. Speed tests unloaded are consistently and repeatedly right around 1Gbps.

What needs to be done to fix this?

---

And come on, stop calling it "Wave MLO6". Wave is 60GHz. Wave is an incredible product that we're still consistently buying and deploying and growing our network.

@UI-Team

I've currently got a setup with two NanoStation M2s linking two buildings 225 meters apart, on two different properties, with around 60 meters of foliage (shrubs, smaller trees, on property not owned by me) obscuring LoS, as described in the thread Setting up wireless link, 225 meters, 60 meters through vegetation. It's good enough to send weather station data and stills from a camera in the winter and fall/spring, but in the summer the signal is very weak and the connection is often lost, especially when it's (been) raining.

So I'm looking at ways to improve things. I've got a Bullet M2 and a Rocket M2, and figured that using them instead of the NanoStations might work.

For the Rocket M2 I've got an RF Elements SECM290 antenna (14 - 14.7dBi gain, https://rfelements.com/assets/Uploads/Datasheet-Sector-MiMo-Antennas.pdf), and for the Bullet M2 I've got a D-Link ANT24-1400 (14dBi, https://www.dlink.com/no/nb/-/media/business_products/ant/ant24-1400/datasheet/ant24_1400_datasheet_en_uk.pdf). Better than the NanoStations' 10.4-11.2 dBi, but not as good as the PowerBeams (18dBi) suggested in the older thread.

Before I go to the site and mess around with the setup, I've got some questions:

Considering that Rocket is MiMo and Bullet is not, is it a good idea to set up a link with a Bullet at one end and Rocket at the other? Are there any disadvantages using Bullet+Rocket?

Would it be a good idea to use YAGI antennas instead of the ones I've got? Something like https://www.newark.com/rf-solutions/ant-2yag16/ant-2-4ghz-yagi-2m-coax-sma-16dbi/dp/69W6488 or https://www.amazon.com/Tangxi-Antenna-Wireless-Aluminum-Directional/dp/B07X3RJZWR/ ? Is the Amazon antenna worth considering, or are they generally of poor quality? I figure that for the Rocket, perhaps I can use two YAGIs, both pointing at the Bullet, one with the directors horizontally and the other with the directors vertically, but I'm not good at antennas so I don't know if that's a good idea or not.

What if I use two Bullets instead of Rocket+Bullet? I might be able to get another Bullet M2, without antenna so I'd still have to get an antenna (perhaps a YAGI as above?).

Any help is appreciated.