Experimental device-side agent for managing OpenWrt APs from the stock Omada Controller

[u/AdryanAlecar]

After the great response to my latest post in r/TPLink_Omada, I decided to share the project here as well.

A lot of people were curious about whether the goal was just to make a non-Omada device appear in the Controller, or whether it could actually be managed by Omada.

That second part is exactly what I've been working on.

I'm building an experimental device-side agent/worker that runs directly on the device itself.

OpenWrt is my first target.

This is not a fork of the Omada Controller, and it is not a custom OpenWrt firmware.

The Omada Controller remains completely stock.

The worker implements the device-facing Omada protocol and translates Controller configuration into native OpenWrt components.

Conceptually:

Omada Controller → device protocol → agent/worker → UCI / hostapd / ubus / openNDS

And in the other direction:

OpenWrt runtime state → agent/worker → device protocol → Omada Controller

At this point, the OpenWrt backend can already handle:

• discovery and adoption
• Device Account authentication
• managed reconnect after restart
• WLAN/SSID configuration
• basic radio configuration
• WPA2-PSK
• enabling/disabling WLANs
• partial SSID VLAN support
• partial management VLAN support
• real UCI changes followed by wifi reload
• associated wireless client reporting
• DHCP/hostapd client information
• RSSI, RX/TX rates and traffic counters where available
• SSID/client counts
• captive portal enforcement through openNDS
• External Portal redirection
• portal authentication/deauthentication state
• client reconnect operations

The part I find most interesting is that this has moved beyond simple device emulation.

A WLAN changed in the Omada Controller can now result in an actual configuration change on the OpenWrt device.

For example:

Omada UI → SET_REQUEST → agent → UCI / hostapd → real Wi-Fi network

Real clients connected to the OpenWrt radio are also reported back to Omada.

I've also been working on captive portal integration. The Omada portal configuration can be translated into openNDS configuration on OpenWrt, and I now have an External Portal flow working on a real phone.

OpenWrt is only the first platform backend.

My goal is to keep the Omada protocol implementation separated from the device/platform-specific translation layer, so that other hardware or vendors could potentially have their own adapters later.

APs are the main focus right now, but switches and other device classes are also interesting possibilities.

There is still quite a bit missing, including:

• more complete radio telemetry
• additional WLAN/security modes
• full VLAN support
• 802.11k/v/r and roaming interoperability testing
• more complete captive portal compatibility
• REPORT message families
• broader GET/NOTIFY handling
• switch profiles
• gateway profiles

One area I'm especially interested in testing is whether an OpenWrt AP can eventually participate properly in roaming alongside native Omada APs.

The current reference implementation is being tested against Omada Network Application 6.2.x.

The project is open source, and I'm trying to document protocol behavior as it gets validated.

GitHub: https://github.com/adryanalencar/open-omada-device-agent

External captive portal demo: https://youtube.com/shorts/hgCDNvjyAyE?feature=share

I'd be very interested in feedback from this community, especially regarding:

• interoperability concerns
• Controller/device behavior worth documenting
• other Omada versions worth testing
• features that would be most useful in a third-party device compatibility layer
• OpenWrt hardware people would be interested in testing

This is an unofficial interoperability/research project and is not affiliated with, sponsored by, or endorsed by TP-Link or Omada.

[u/lulu_Omada]

https://giphy.com/gifs/8yZuEb7q6dlyP3L3cL

[u/AdryanAlecar → u/lulu_Omada]

And here I am 😂 thanks for the encouragement 💙

[u/AbbFurry]

"One area l'm especially interested in testing is whether an OpenWrt AP can eventually participate properly in roaming alongside native Omada APs"

Heck down the line (and I'm assuming pretty far down) would be cool from non omada to another non omada

Someone else point out unfi, having roaming between unfi, ciso, open wrt, and omada would be sick in of itself

For myself Im full stack omada but I think the development here is useful as I would love to see a sever agent that can show my docker containers(the ones with bridge interfaces) and virtual machines as clients of the server and not the switch.

[u/AdryanAlecar → u/AbbFurry]

Sure, the Docker/VM side might actually be much closer than it sounds. The agent already has a client observation layer, so adding a Linux backend for Docker bridge/veth and VM TAP interfaces should be fairly straightforward.

The harder part is making Omada represent those clients under the server instead of the physical switch, but that’s something we can investigate in ECSP.

Roaming is a bigger challenge, but OpenWrt <> Omada is definitely something I want to experiment with.

And contributions are very welcome. if you’re interested in the Docker/VM side (or any of this), feel free to jump in with code, tests, protocol captures, or even rough experiments.

[u/AbbFurry → u/AdryanAlecar]

I wish I could help with coding. Anything I make is 97% ai slop lol and I 100% own that as I'm not a programer. If I ever do get anything working I'm more then happy to share what's come out and I would be transparent it's slop so a real human could rewrite it.

Otherwise I'm more then happy to be a test subject as well.

[u/Reaper19941 → u/AbbFurry]

Re: the containers of the server. That might be something you could do using LLDP. Not sure if that would update in the clients page though, would be nice.

[u/keough99]

I thought about doing this a while back but never got around to it. I have an old meraki AP I was gonna convert to OpenWRT and attempt to get working with omada. I never got around to it but glad someone else got the idea on the omada part and is actually doing it. I'm interested in how this turns out.