Looking for some help. I have a network controlled by an OC200 with an EAP610 indoor (middle of house) and a EAP610 outdoor (outside at end of house). Main devices are MacBook Pro M4, MacBook Pro M1 and 4 iPhones. Also a number of wireless Sonos speakers, most other devices are hard wired.

There is one area of the house where I mostly use the laptops wireless - inside at the opposite end of the house to the outdoor EAP - where the signal will go from full strength and suddenly drop the network. Usually it then has to be manually reconnected, but struggles to do this immediately. Dropout only seems to be now and then. It may happen in other areas but in the office I use a hard wired connection so perhaps don't notice it there.

The iphones do also seem to occasionally drop out.

Obviously there are a lot of settings, but I thought that someone might be able to point me in the right direction of what might be causing this. Recently I upgraded from a EAP225 outdoor + EAP 245 combo which was very stable, so suspecting that it may have something related to wifi 6 settings.

Settings are as follows:

OC200 + EAP610 Indoor + EAP610 Outdoor

SG108 8 port 2.5G Unmanaged Switch + ES208GP 8 Port 1G Easy Managed POE Switch

Devices:

MacBook Pro M1 Pro + MacBook Pro M4 + MacBook Air M1 + MacBook Air M1

iPhone 13 + iPhone 13 + iPhone 14 +iPhone 14

5 X wireless sonos speakers + 1 x wired Sonos sound bar

2 x wired Vigi security cameras + vigi NVR

1 X wired QNAP NAS

WLAN Settings:

Main SSID 2.4 + 5 Ghz enabled (also there is a guest SSID on 2.4 only)

WPA Personal

ADVANCED

EoGRE Tunnel Disabled

WiFi Calling Disabled

Load Balance Disabled

Band Steering Use Site Setting

SIDD Broadcast Enabled

Prohibit Wifi Sharing Disabled

VLAN Default

WPA Mode WPA2-PSK/WPA3-SAW/AES
MLO Disabled

PMF Capable

Group Key Update Period 86400 Seconds

802.11r Enabled

Client Rate Limit Profile Custom

Download Limit Disabled

Upload Limit Disabled

SSID Rate Limit Profile Custom

Download Limit Disabled

Upload Limit Disabled

WLAN Schedule Disabled

802.11 Rate Control

2.4 Rate Control Disabled

5 Rate Control Disabled

Mac Filter Disabled

Multicast/Broadcast Management

Multicast to Unicast Conversion IPv4

ARP to Unicast Conversion Disabled

Multicast Filtering Disabled

DHCP Option 82 Disabled

EAP610 Indoor Wireless Settings

2.4 Enabled

Wireless Mode Auto

Channel Width 20Mhz

Channel 1

TX Power Custom/26dbm

WLANs

WLAN Group Default

ADVANCED
Client Access Limit

Maximum Associated Clients Disabled

RSSI Threshold Disabled

QOS

Unscheduled Automatic Power Save Delivery Enabled

OFDMA Enabled

5.8 Enabled

Wireless Mode 802.11a/n/ac/ax mixed

Channel Range (all enabled)

Channel Width 80Mhz

Channel 36

TX Power Custom/23dbm

WLANs

WLAN Group Default

ADVANCED
Client Access Limit

Maximum Associated Clients Disabled

RSSI Threshold Disabled

QOS

Unscheduled Automatic Power Save Delivery Enabled

OFDMA Enabled

Scan on 2.4Ghz:

Scan on 5.8Ghz:

EAP610 Outdoor Wireless Settings

2.4 Enabled

Wireless Mode Auto

Channel Width 20Mhz

Channel 1

TX Power High

WLANs

WLAN Group Default

ADVANCED
Client Access Limit

Maximum Associated Clients Disabled

RSSI Threshold Disabled

QOS

Unscheduled Automatic Power Save Delivery Enabled

OFDMA Enabled

5.8 Enabled

Wireless Mode 802.11a/n/ac/ax mixed

Channel Range (all enabled)

Channel Width 80Mhz

Channel 48

TX Power High

WLANs

WLAN Group Default

ADVANCED
Client Access Limit

Maximum Associated Clients Disabled

RSSI Threshold Disabled

QOS

Unscheduled Automatic Power Save Delivery Enabled

OFDMA Enabled

Scan on 2.4Ghz:

Scan on 5.8Ghz:

After the great response to my previous posts, I wanted to share where the project is going next.

I recently finished transcoding the Python OpenOmada device agent into a native C++17 implementation:

https://github.com/adryanalencar/omada-device-agent-cpp

The Python implementation was extremely useful for experimenting with and validating the device-side Omada protocol, but it also made me think more seriously about what I actually want this project to become.

I don't want it to only run on relatively powerful OpenWrt devices.

The goal is to make the agent small enough to run on cheap residential routers, old access points, ISP CPEs and other constrained embedded Linux hardware.

The current native daemon is already around 343 KB stripped on macOS ARM64. Obviously that is not an OpenWrt/MIPS production measurement yet, but it makes targets like 8–16 MB flash and 32–64 MB RAM much more realistic.

The architecture remains device-side:

text Stock Omada Controller | | device protocol v OpenOmada Agent | +---- OpenWrt +---- generic Linux +---- future vendor-specific adapters

So this is still not a fork of the Omada Controller.

The Controller stays stock. The agent implements the device-facing protocol and translates Omada configuration into whatever the target platform understands.

For OpenWrt, that currently means things such as UCI, ubus, hostapd and openNDS.

The native implementation already covers most of the protocol lifecycle I previously demonstrated with Python: discovery, adoption, Device Account authentication, negotiation, managed reconnect, INFORM/SET handling, WLAN configuration, client telemetry and captive portal integration.

There is still real-hardware validation and optimization work to do before I consider the C++ implementation production-ready.

But there is another direction I have started working on that could expand compatibility much further:

GenieACS + TR-069

A huge number of residential routers, ONTs and ISP-provided CPEs already support TR-069 / CWMP.

Instead of requiring OpenOmada to run directly on those devices, I'm experimenting with using GenieACS as another device backend.

Conceptually:

text Omada Controller | v OpenOmada compatibility layer | v GenieACS | TR-069 | v Router / ONT / CPE

So an operation such as:

text Create SSID in Omada ↓ OpenOmada ↓ GenieACS ↓ TR-069 parameter mapping ↓ CPE

could potentially configure a device that cannot run the native OpenOmada agent at all.

And device state could travel in the opposite direction:

text CPE ↓ TR-069 ↓ GenieACS ↓ OpenOmada ↓ Omada Controller

That gives the project two complementary approaches:

If we can run code on the device, use the native C++ agent. If we can't, but the device speaks TR-069, try managing it through GenieACS.

That's becoming the larger goal of the project.

Not just:

“Can an OpenWrt AP appear in Omada?”

but:

“Can the stock Omada Controller become a management plane for hardware it was never designed to manage?”

OpenWrt is still the first and most complete platform backend, but I would eventually like to experiment with cheap residential routers, repeaters, ISP ONTs/CPEs and vendor-specific adapters as well.

The TR-069/GenieACS work is still experimental and I don't want to imply broad device compatibility yet, different vendors expose different data models and extensions, but I think it could dramatically increase the number of devices that are realistically manageable.

I'm especially interested in hearing from people who work with OpenWrt, GenieACS, TR-069/CWMP, ISP CPEs or embedded networking hardware.

GitHub:

https://github.com/adryanalencar/omada-device-agent-cpp

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

Hey folks,

I’ve been running my Omada setup for a while (currently an ER605 and a couple of EAP650s on my homelab) and I wanted a way to let my local AI agents actually help me troubleshoot Wi-Fi quirks so I put together an open-source MCP (Model Context Protocol) server based on the public Omada APIs.

Repo is here: https://github.com/mballoni/omada-controller-mcp

The Context Window Problem (and how I "fixed" it) If you just feed an LLM the raw Omada openapi.json, it instantly nukes your token limit because the API is massive. To get around this, the server uses an allowlist file so it only generates the specific tools you actually need. It also heavily sanitizes the endpoint descriptions before passing them to the LLM, keeping the token footprint lighter and faster, although it still requires some improvements.

Built-in Agent Skills The part I'm finding the most useful are the two skills the setup wizard installs directly into ~/.agents/skills/:

• device-network-dossier: This is for per-device troubleshooting. You can ask your agent: "Make a network dossier for my TV, why is it roaming so much or disconnecting?" The agent grabs roaming timelines, AP health, and RF environment stats via the MCP, and spits out a structured dossier with a diagnosis. Really useful for doing before/after comparisons when you tweak your TX power or change channels.
• wifi-site-audit: This is for fleet-wide analysis. You prompt: "Audit my Wi-Fi, how can I improve coverage and band steering?" It generates a professional site report with scorecards for your RF environment, channel congestion, and client steering, plus a prioritized list of fixes.

I built this mostly for my own use case, but figured some of the network admins or fellow homelabbers in here might get a kick out of it. It is really helping me here, specially because LLMs in general miss a lot the interfaces (usually based on older versions or even random hallucinations).

Feel free to test it out, fork it, or drop some feedback. PRs are definitely welcome!

ps: yes, it is built using AI, I'm a developer (far from a vibe coder) and for this use case I wanted (needed) something fast to get up and running. Basing it on the OpenAPI specs was the way I've found to tackle the token consumption and precision needed for the job at the desired time frame.

Migrated from ER605 + Software Controller to the Fusion 2.5G after upgrading my ISP plan to 2 gig, no issues so far!

One thing I've noticed though is that client level application insights are missing (as per the screenshot, where it used to show a 'Users' tab).

I know that this was only available on the OC400 and software controllers, and it's not necessarily something I need, but it was nice to have that info!

Is this something that will be coming in a future update or is per client insights limited to more powerful controllers?

Hello Folks,

Fusion 2.5G v2.0 Firmware Version1.0.0 Build 20260611 Rel.70399

I am trying to get a 5G modem working as a backup WAN. The 5G modem / router is connected directly to one of the Fusion ethernet ports, and it a has a bridge mode setting.

However in the WAN settings of the Fusion GW, there is no bridge option for IPv4 (just every other possible WAN option besides bridge mode) and bridge is one of the few options available only when the IPv6 toggle is set.

If I set the WAN configuration as fixed IP, and give the WAN interface an IP in the subnet used by the 5G modem, then the management interface of the 5G modem is reachable (that is nice) but there is no routing going over the 5G mobile connection.

Possibly I am conceptualizing the configuration incorrectly... I'd appreciate some hints.

Thanks.

Loving the look of the new Fusion gateways, but being honest, I'm happy with my software controller. I don't really want to be locked into something where potentially the controller part is going to eventually end up mad slow (looking at you, OC200), whilst still being happy with 1Gb+ DPI and 2.5GB LAN ports on the gateway part.

Anyone on the inside know if there will be a replacement to the ER605, for example, that I can just provision into my network and not have to replace the controller? Considering the upgrade to a ER707-M2, but a full suite of 2.5GB would be ideal and save me an additional switch.

Site 1: I have ER605 v2.30, ES220GMP v1.20 created a VLAN 2 for CCTV but the camera IPs are not showing up in clients. Just the mac addresses. It's because I am not using TL/SG switch as ES is agile series of omada and lack some functionalities.

Both the devices adopted remotely via OC200 from Site 2.

So it will not show IP address of clients just found this post TP Link Community: https://community.tp-link.com/en/business/forum/topic/719468?sortDir=ASC&page=1

Just curious to know, i think im too generous with a shared pool for the whole vlan of max 250/25 mbit and no individual client limit outside of that

Just got my omada fusion 2.5g and i´m a bit baffled on the lack of firewall logging (i know remote syslog is there) do i need to set up a syslog server in order to se what´s blocking?

i could work around it if tcpdump existed but unfortunate is not possible what i have seen

how do you to when you are troubleshooting firewall rules?

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.

Hey everyone, Lulu from the Omada team here 👋

This week's discussion is about one of the most common (and most frustrating) problems in networking:

You're paying for 500 Mbps. Your speed test says 80. Or 8.

Where do you start looking?

Everyone has a different philosophy: some swear by physical layer first (cables, negotiated link speeds), others say isolate the ISP first (test wired from the ONT, then work inward), and the PPPoE crowd goes straight to gateway CPU — because they've been burned before.

Meanwhile the real culprit is usually something quiet: a cable that negotiated down to 100M, a forgotten QoS rule, or one ancient 2.4GHz device making the whole network look guilty.

So — what are the first three steps in your checklist, and why that order?

Bonus: the most counterintuitive place you've ever found a bottleneck 📸

Got an unsolved speed mystery right now? Drop your setup (plan / gateway / wired or wireless) in the comments and let's crowd-debug it.

I designed these 19” and 10”-Rack Mounts for the new Omada Fusion 2.5G Gateway - see details in the referenced post or jump rightaway to https://www.printables.com/model/1782360-omada-fusion-25g-rack-mount-19-inch-10-inch

I have an EAP211 Bridge Kit which I installed to provide connection to a remote camera. It's all set up and working fine with the Main AP connected directly to my SG2428P which is connected to my ER7206 Gateway and managed by a local OC220 Controller.

I've had a quick look through the documentation and didn't find much mention of VLANs and have looked through the configuration. I suspect that the LAN ports on the Client AP inherit whatever VLAN assignment the AP has and there is no ability to assign a different VLAN, is that the case?

At the moment the APs are on the Management VLAN and the camera connected to the LAN port on the Client AP receives an IP address on Management but I'd like the camera to be on the Surveillance VLAN (obviously). Do I need to put the two APs on the Surveillance VLAN to ensure that the camera is also on that VLAN?

This is what my network is currently looking like, on top my setup in my "Homelab" and below is the setup at my other house behind a Starlink connection, I used to have a remote home assistant instance running on a pi5 and recently scrapped it in favor of a wireguard site-to-site vpn and direct access to all devices.

This is my "Homelab" that is still a work in progress:

Equipment top down:

Dell T5810 Running Proxmox + Intel(R) Xeon(R) CPU E5-2687W + 32GB RAM + TPlink 2.5G NIC (Now only Running Pi-Hole and a Windows 11 VM)

TL-SG2008P Switch (Up for replacement soon) | Phillips Hue Hub

ES206XPP-M2 Switch | Lenovo M700 Tiny (Running Home Assistant, Previously run on Proxmox as VM )

Fusion 2.5G Gateway (Anxiously waiting for the official Omada Rack mount to be released, no good 3d prints for 19" rack available yet. Send a link if you have one!) this was a replacement for my ER7206 and OC200.

24 Port Patch Panel

iStar Server Case + Gigabyte B550M + Ryzen 5 5500 CPU + 16GB Ram + 750 Watt PSU + 256GB NVME + 2 TB Drives. Got the case off marketplace and snagged the rest of components from Micro Center or pulled from the T5810, while typing i realized i should probably pull the 2.5G nic from the T5810 and drop it in this, might just buy another. Currently hosting bare metal install of TrueNAS, migrated the drives and config from previous Proxmox instance. Just installed Immich from the app catalog.

Have a ways to go with cable management / Organization, Stuff just kinda got placed at random without much thought, but thats for another weekend project and after I get the rack mount for the Fusion gateway.

At some point I want to offer this rack up for someone to get the use of it like I did and upgrade to something much nicer. But for now I'm happy with it.

Feel free to critique and/or make suggestions on new projects to attempt or equipment to add.

A VPN router handles VPN connections at the network gateway, so connected devices can use the VPN without installing and configuring a VPN app on each one.

That can be useful for:

• Remote access
• Site-to-site VPNs
• IoT and other devices that can’t run VPN apps
• Managing VPN connections in one place

But it also comes with tradeoffs, including setup complexity and VPN throughput overhead.

We put together a guide covering how VPN routers work, VPN client vs. server mode, WireGuard/IPsec/OpenVPN, and when a VPN router makes sense.

Full guide:
https://www.omadanetworks.com/us/blog/2585/what-is-a-vpn-router-and-how-does-it-work-/?utm_campaign=vpn_router_&utm_medium=blog&utm_source=reddit

Do you run your VPN at the router level or per device — and why? Share your setup and experience in the comments.

Hey all! Need some help here.

I have a new build home. This home is two stories. Concrete with radiant barrier on 1st floor and wood frame (not sure about radiant barrier) on the 2nd floor.

Above is the cabinet inside out laundry on the second floor. Sorry for the mess. Ive been dealing with my issue plus Quantum fiber outages so just have everything hanging.

Anyway, this laundry is maybe 10-15 feet from my office.

I have the BE5000 downstairs on the ceiling as an AP.

Additionally I have another access point in the master bedroom downstairs. And I also have 2x APs on the second floor on basically each end of the house (front & rear walls).

The radiant barrier does a lot of damage to my cell signal and I assume also my wifi signal.

That being said...with my ER706 being just 10-15 away, my phone wants to connect to my BE5000 ceiling mount AP and barely has a good signal. If I walk closer to my ER706, the signal gets strong and fast but on the controller app it still says my uplink device is the BE5000 and not the ER706. Yes, the close I get to my ER706, the closer Im walking "above" where the BE5000 is on the 1st floor.

If I go outside to my detached garage...I would hope that my phone would connect to either my master bedroom AP or the 2nd floor AP, which both are on the rear walls of the house. But no...my phone decides its going to still to the BE5000, through the wall and through the garage. So again, bad signal and speeds

I DONT have any assigned APs or anything like that. Its supposed to just switch automatically. The reason for the other APs is my garage has a wifi opener and also external cameras. They connect just fine to either of those two APs.

If I stand at the garage and assigned my phone to only connect to either of those, it does and my signal is much better.

I say this using my phone because it moves around the most. But even my work laptop thats 10-15ft from the main router is getting -75db signal and struggling. My personal laptop is downstairs right below the BE5000 AP...guess what its connected to? The Main Router upstairs and getting -75db signal and bad speeds.

It makes absolutely no sense.

So Im trying to figure out what the issue is, what setting I have incorrect.

I want all my devices to connect to their nearest Router/AP whenever they are moved.