the brief
Open-Mesh, the US company behind a line of cloud-managed Wi-Fi mesh access points (later acquired by Datto), ran an agent on every device it sold. It reported health and statistics to the cloud, received configuration, and kept the mesh alive.
We joined the team working on that agent to improve it, extend it and debug it, and stayed for around five years. A couple of years later, the same approach was brought to a newer generation of cloud-managed hardware, and we worked on that for another two. Across the two, the agent ran on somewhere between 120,000 and 150,000 devices in the field.
the hardware range
The hard part was never the agent’s logic. It was making one agent behave the same way on everything.
At the bottom of the range sat the OM1P: a 180 MHz single-core MIPS chip, 32 MB of RAM, 8 MB of flash, and 802.11b/g. Devices in that class were eventually dropped by OpenWrt itself, because there was no longer room to run a modern, secure system on them. The agent had to live inside that budget.
At the top, in the later generation, came quad-core ARM platforms such as the IPQ40xx family, with eight times the memory and 802.11ac Wave 2, and then Wi-Fi 6.
In between: two CPU architectures, four Wi-Fi generations, and a mix of OpenWrt builds and vendor SDKs. The cloud needed to see all of it as one consistent fleet.
one interface
Most of the fleet ran OpenWrt with the mainline Qualcomm Atheros drivers: ath5k, ath9k, ath10k and ath11k. Whatever their differences, all of them sit under cfg80211 and speak nl80211, the standard Linux wireless interface. So the agent collected its data through that single interface, and a statistic from an old OM1P looked the same in the cloud as one from a current access point.
The approach carries forward. Newer drivers such as ath12k and Wi-Fi 7 hardware fit the same model without the agent changing shape.
extending the kernel
A standard interface is only useful if it exposes what you need, and in the early 2010s nl80211 didn’t expose everything. When a driver or the interface itself was missing something, we didn’t work around it in the agent. We added it to the kernel, and upstreamed the change.
In 2012, for example, there was no way for userspace to ask an access point interface through nl80211 which SSID it was serving. We added it, in two patches merged by the Linux wireless maintainer (one, two), and tools like iw still read it that way today.
In 2014 we added expected throughput per station to cfg80211’s station API. The agent reported it to the cloud, and the batman-adv mesh protocol now uses the same value for its routing decisions.
Those changes have been part of mainline Linux ever since.
vendor drivers
Not every device ran a mainline driver. Some ran vendor SDKs with their own Wi-Fi drivers, which ignore cfg80211 and nl80211 entirely.
There, the standard path simply doesn’t exist. We found other ways to extract equivalent data from each vendor driver, then normalised it inside the agent until it matched what the mainline drivers reported. The cloud never knew the difference. A device running a proprietary driver showed up with the same metrics, in the same shape, as every other device in the fleet.
mesh self-recovery
These were mesh devices, and a mesh node that loses its path can’t be fixed from the cloud, because the cloud can no longer reach it. So the agent had to recover on its own.
When connectivity dropped, it could instruct the driver to go beyond normal operation, switching the radio into special modes to find its neighbours and rebuild the mesh. That only works if the kernel behaves correctly at the edges, and in places it didn’t. We fixed those too: sending management frames on the current channel without having to specify one, and a bug in IBSS joins that could leave cfg80211 and the driver disagreeing about which channel they were on.
results
The agent ran across the Open-Mesh line for around five years, and then on the next generation of hardware for another two. In total it was deployed on 120,000 to 150,000 devices.
Along the way, the fixes and extensions it needed went into mainline Linux, where they were reviewed and merged by the wireless maintainer and are still in use.
what it took
Plenty of teams can work on a cloud agent. Far fewer can keep one behaving identically on 32 MB MIPS boards and Wi-Fi 6 access points, go into cfg80211 when the data isn’t there, get the change accepted upstream, and still produce the same numbers from a proprietary driver that ignores the standard interface.
That mix of embedded, kernel and wireless work is what we do every day. And it slots into an existing team and codebase, which is where most of this work actually happens.
if this sounds familiar
If you have a cloud-managed product whose agent has to run across hardware you don’t fully control, and it isn’t keeping up, that’s the problem we solve.
Just book a call and let’s discuss.
More about our wireless and mesh work · Our open-source contributions to the Linux wireless stack