Introducing myself: I'm a 30+ years experienced network veteran, teaching core networking cybersecurity courses, training instructors in Europe in networking (including a lot about IPv6).

My home network was up for an upgrade, after an old 802.11n Linksys access point radio (2.4 GHz) died on me. I did some research and found that the Omada line of products with a controller software would fit my needs perfectly. I don't have a "company" network at home, but of course, I do have some needs that I wanted fulfilled. I don't have corporate budgets, and the Omada ecosystem seems like a nice 21st century solution.

The plan was to start with a single new access point, trying to figure out how to configure it, and test some the things in this environment for later evolutions. The plan was to expand this to 3/4 AP's (replacing my other existing ones) and include switches and even (though not sure/convinced about that) an edge router/firewall in the future.

I listed my wireless needs as follows:

1. Wifi 6
2. Multiple SSIDs (didn't have that now, but the introduction of some Home Automation really warrants this, for security reasons, and the possibility to use IPv4 on that SSID/VLAN ONLY)
3. 802.1Q VLAN support
4. REAL IPv6 support, IPv4 is no longer being maintained even, so IPv6 for everything (including ALL management) is a MUST on all hardware.

I also had some "nice to haves" but I haven't gotten to testing those, yet. A strict 802.1X possibility for a single SSID/VLAN is just an example, as is some throttling, and QoS. But those are secondary to the first 4 requirements.

So I decided to start with a simple setup: a single EAP650 to replace the failed Linksys access point and a dockerized controller (with the possibility to migrate to a hardware controller if everything worked fine and grew).

If I seem a bit bitter in this post, it's because I'm hugely disappointed. Because I did ALL the research I could do, and still it's not good.

Problem #1

The IETF is no longer doing anything on IPv4, for them the current protocol is IPv6. So being able to manage a device over IPv6 is a MUST, certainly if you look at  EU rules that mandate everything connected to the network starting soon somewhere, MUST truly support IPv6.

I read about the commitment of TP-Link towards IPv6. I applauded that in front of ALL of my students, it was an absolute thrill for me to read it, and still that was the first big (really enormous) disappointment. There's NO functional parity at all, even though I seemed that way in the documentation.

Number one rule in IPv6 is: NEVER use addresses, ALWAYS use names (actually, that was also my motto for IPv4, as it should have been for everyone since the DNS RFCs from 1987), so I was expecting an onboarding mDNS name to find the AP over IPv6, but nope, had to go over IPv4, using information from my DHCPv4 server. Bummer.

I also tried to find the IPv6 address of my dockerized controller, and apparently it's just not there, even though it is configured as "host" like the docker-compose file explains. It is Linux, it should support IPv6, but it seems like the "commitment" is not that strong.

It was not clear in the documentation I got, but apparently I had to configure the AP as standalone first, and then have it announce itself to the controller. This was not really clear, but once I figured that out: no option to use IPv6.

Because if the commitment were real, it would be possible to configure a DNS-server, so names could be used. Also it should be possible to choose the Layer 3 protocol over which to send this announcements.

This would  facilitate troubleshooting for the coming years where dual stack networks will be more and more common. I might be willing to go to IPv6 only as quickly as possible, and DEFINITELY on my core networking infrastructure, but not everyone might be that committed.

Again it seems like the AP runs Linux inside, and IPv6 support in Linux is definitely strong and very (I've been a core Linux user for 25+ years). So again, this seems like a GUI problem - again. Because, technically speaking the underlying system could easily handle this.

Another IPv6 related GUI problem is in the controller software itself. If you want to see the IPv6 address of your access point, you could be out of luck.

In my home network-case with IPv6 PD in use, I also need to use ULA. The controller interface (even though more addresses are picked up by the AP) ONLY shows a maximum of 2 address, one of which (the LLA) is mostly completely useless in my case. So sometimes I see only the LLA on the devices page (which I don't really care about, as I have a multi VLAN environment), sometimes the LLA and ULA, sometimes the ULA and GUA, and sometimes the LLA and GUA... Not really logical, right?

It would be great to see the ULA (if it exists) AND GUA at the same time, and please make it possible to copy paste that (I need those kinds of things to add them to DNS). Now the space to see these in the GUI (again a GUI problem) is so petite that addresses (which ARE longer in IPv6, nothing anyone can do about that now) are almost never readable, let alone copy/pasteable.

I can understand showing an LLA if there's no GUA or ULA, but what is the point? It's not like I'm going to place my AP and my management laptop in the same VLAN, EVER... and as I explained, PD can have my GUA change, so I need a stable IPv6 ULA. Companies with a fixed prefix would not have this problem, and they should not really be using ULA at all.

It would be great to be able to add the DNS-name of a device and a way to have the controller update DNS, or at least see the addresses completely. It would also be better (but now I'm listing the minor points here) to speak of "IPv4" and "IPv6" and NOT "IP" and "IPv6", if anything the current "IP" version is "IPv6". Naming parity should be part of the IPv6 commitment.

And while we're at it, make it possible to configure the controller URL for the announcement of the AP to the controller possible in DHCP and/or DNS.

So it seems I will either have to sell this AP and find a manufacturer that truly supports IPv6 ONLY if wanted it, and truly supports IPv6 in the configuration interface, OR I will have to accept the fact that at this price point, investments in preparing for the future will take a few more years or even decades, and continue to use IPv4 in the meanwhile.

But if problem #2 persists, that is not even an option.

Problem #2

If you thought my disappointment was complete after problem #1... It got worse. Today I had to restart the AP, because I could no longer obtain an address after connecting the the AP. This was a surprise, as the AP has NO L3-7 responsibility AT ALL. All it should do is forward the wired traffic to my wireless devices, INCLUDING DHCPv4 and RAs, and today it failed to do so.

To be honest, I checked today, and my AP used firmware version 1.0.14, and I updated it after this problem to version "1.1.0 Build 20240830 Rel. 50826". I hope this solves this problem, because if it persists, my new AP is nothing but e-waste, and I couldn't even sell it to anybody else, because I would NOT want to be responsible for that.

Another disappointment is the range... It seems like my single Linksys device will have to be replaced by 3 EAP650s to cover the same area (can't even stand behind the wall 3 meters from the AP, while the ancient Linksys would still connect and work standing 12 meters away, with two walls in between). But I have NOW manually configured the TX power to maximum, and will re-evaluate this problem as well. Because that problem was before the firmware upgrade, and I will test again if everything else works and I can remount the AP to the ceiling.

Again, I DON'T believe these problems are hardware related, but I believe all of them to be related to buggy software. I downloaded some logs, and it seems to me like the AP is using Linux as well, which is great. I really like that - a lot.

But I can create an access point with only a Raspberry Pi and a cheap USB Wi-Fi dongle, and have it running stable for months at a time, so an TP-Link. I don't believe that the hardware would be lacking, so I think this might have been another software problem.

If it is, it would be nice to have some REAL logging. I have been looking at how to connect my AP or Controller to my home syslog-server, but I can't find that functionality in the Controller Config-panel, which again, should be a no-brainer, AND is definitely supported by the underlying Linux systems.

My Question:

Somehow, I feel TP-Link is willing to create good software, and if you look at that range of products, and definitely the Omada-related products, it seems like NONE of the problems above should happen, as there are aimed for company use with expectations that are way, way higher than mine.

I am willing to share my experiences (and the ones I pick up from the companies I work with) to suggest improvements, and there are quite a few potential improvements listed in the text above. Is that an option? And at the very least: how can I solve the problems I outlined above?

I'm offering this, because only a year or so ago, my ISP had a similar situation, and apparently I was the first residential client with this IPv6 knowledge, and it helped them adapt the firmware in their cable modems (and solve my problems too)

So please, what do I have to do next?