Unifi Ubiquiti and TP-Link Omada

Continuing the discussion from Why does duplicacy keep failing due to invalid licence when I have a valid license?:

I also had a Dream Machine, the small one, but but because of stuff like what you describe, I switched to Omada before buying more Unifi stuff. I was mailing with Ubiquiti level 2 (or 3) support for months and in the course of that process it became apparent to me how much is going wrong at that company. They were churning out firmware releases at a faster rate than I was able to install them and each release, while allegedly fixing something, also broke something. And just after they had a major security breach in their cloud services, they started forcing people to create a cloud account to be able to setup their device. My interpretation was that much of their growth was due to good influence marketing, which took resources away from the R&D budget (or quality control, for that matter). I reluctantly sold my beautiful dream machine and never looked back.

We still don’t hace mDNS, though. But it‘s coming (the controller supports it since a recent update, now they have to update the device firmwares… But it’s exactly this slow release cycle that made me more confident to buy their stuff. Unifi would have released it all in one and as early as possible and then fixed all the bugs for years.

oh yes… that was the time… At some point I just picked a least broken software that worked well for my purposes and turned off updates. Reading forums and walking on eggshells after every release wasn’t that much fun. Same deal was with access point firmware. How did they manage to make Qualcomm/Atheros AP less stable than Mediatek based ones still baffles me.

Recently however (last few years) it has become pretty stable. I’ve re-enabled the auto updates, and so far had no issues. I forget it’s three. I mean, the UI is still buggy – e.g. it does not show real time traffic per client correctly, but from the routing, vpn, and Protect perspective – it “just works”. Nothing fancy, but enough for a home network and ocationall remove management.

It does feel that their quality control or any decent release management is nonexistent. It feels they pretty much figure things out as they go, and still operate in a small startup mode, that is not really appropriate at this state of company maturity.

I don’t mind cloud services, I do use them, so I don’t have to deploy my own. I like being able to mange my parent’s network on the other side of the world from the same UI, cameras/Protect is still the fastest and the best performing NVR I have ever tried, and doing basic stuff – VLANs and a basic firewall works. So I guess it’s a win?. I’ve used pfSense, Sophos UTM9, Sophos XG, Untangle, and even old Cisco Catalyst, I think it was 9600 or so, before. Not in that order, and repeatedly, ultimately, settling down on Unifi. I remember amount of time I spent debugging Sophos bugs, and Untangle’s UI was simply repulsive. Cisco support took weeks to respond, with a link to kb, and following their documentation literally did not work. pfSense was fine, but I wanted “just works out of the box” thing, with somewhat limited customizability. The selling point however initially was impeccable implementation of SQM; now that I don’t need it – I still have it turned on, and it still helps lower and stabilize latency even on my 600Mbps connection, even though at such speeds returns are heavily diminished of course.

At the core they were engineering startup, making long range radio links… that’s their core competency. Their routers always were a bit weird even hardware wise – USG4P for example, had an external power supply bolted inside the rack mount enclosure, pretending to be an internal one. Things like that are just bizarre. But they are cute and shiny and can be made to work – so I guess that’s why people like them. marketing is indeed good. They kept calling USG3 Unifi Security Gateway, that got obsoleted before their promises materialized in software.

How is the experience overall? Every time I tried to do anything with TP Link I invariably stumbled on some oddity that made no sense to me other than the company saving money on unsuspecting consumers. Things like 8-port gigabit switches with 2Gbps total combined bandwidth (that you only learn from the data sheet, if you really want to find it), half-arsed network adapters (that have mishmash of looking good on paper “features” and absolutely bare minimum of things that matter), etc.

And now this blatant copy of unifi ui - and not even the most recent one, I guess copying takes time. How about spend time and design something better? Why copy a competitor? This looks like a dead end to me, unless a goal is a short term money grab. Maybe that’s why they don’t invest in support?

It could also be that there are two interns working on this between shifts and they just can’t get anything done… mDNS is literally zeroconf protocol, it should not take ages to deploy.

I honestly don’t know what is better :slight_smile:

So after UniFi do you feel you have more stable solution? Do they support SQM (fq_codel)? Would it makes sense for me to give them another chance?

This got be googling again, and LOL: https://community.ui.com/questions/Traffic-Stats-w-IPv6-Enabled/ab89d7dc-17f7-4661-9909-54657eb07e0f

This is indeed pathetic. But on the other hand the network is stable, I guess I should be happy.

Ubiquiti has been disintegrating for a couple of years now, if not more. Terrible firmware, worse support, a bunch of engineers leaving, privacy/breach issues - the list goes on an on. I wouldn’t suggest UI products to anyone nowadays, and I do own a few pieces of their gear still (some older APs which is probably the best product to own from them if you have to have some).

Have heard good things about Omada’s APs. TP-Link’s 1G and 10G switches are great value for prosumer market, I really like them. Just don’t buy the cheapest models :wink:

According to this mDNS Service - Business Community it should have been already released, this Official Firmware ER7206_1.2.3_Build 20221104 (Released on Nov 10th, 2022) - Business Community does say

2. Add stateful ACL.
3. Add mDNS Repeater.

The two features everyone was complaining about for years (yes, I went to the rabbit hole reading about Omada…) are ready, literally few weeks ago. What a timing.

I suspect this is the case of the grass looking greener on the other pasture, as it almost always is… The question is, is it worth swapping a bucket of known issues with the bucket of unknown, but different ones. So far ubiquiti was stable for me, ignoring the the whole UI and broken features. But I too stopped recommending it long ago, and my patience is running out. I’ll probably throw in a towel at some point and switch to something else.

It’s a lot like duplicacy: solid core functionality, coupled with the UI that really needs a lot of work, and drags down the overall product quality.

Except UBNT’s core functionality is far from solid. They have a long and storied history of breaking core functionality in firmware upgrades, e.g. losing basic connectivity on APs and routers. That’s with official “stable” releases. People were terrified to run any updates, as it would be akin to pulling a pin from a grenade, and hoping that it is not live. You find a firmware version that sort of works for your setup, and then delay upgrades for as long as you can, that was standard MO. Less of an issue for home users, but people were trying to run it as a low-cost enterprise gear…

Some things were not fixed for years, iptv/IGMP snooping issues with UBNT gear were pretty legendary.

1 Like

I guess you are right.

I was doing precisely that for years and it became new normal. But those memory leaks in routers, and crashes in APs were somewhat limited to some especially dark period. Recently (few years ago) I’ve re-enabled auto-updates, and nothing broke since. I do understand how ridiculous this sounds and how low a bar of “not breaking” is for this type of gear…

Anything that is related to measurements and stats never worked, and probably never will… so there is no expectation, and hence, disappointment :slight_smile:

I do too, but I don’t like to be forced to use anybody’s cloud services to use their product. In particular, when your cloud service just had a major security breach (which you didn’t handle exactly well), it’s not such a great idea to - just a few weeks later - start forcing your customers to use exactly that service.

I was also looking at pfSense but I quickly realized that this is not something that will work out of the box and since my (superficial) impression was that the support community didn’t seem particularly welcoming to people like myself who basically have no clue about networking, I quickly ruled that out as an option for me.

I didn’t even know that existed. Had to google and then test what I’m missing, but I seem to be fine:

Screenshot_2022-12-06_07-30-39_PM

I do have some lag sometimes, though, and I haven’t quite figured out what causes it, but the most likely cause is my use of pihole/NextDNS. Some pages can’t handle blocked DNS domains (or they deliberately do so, IDK).

Yes, when you have to google to find out whether you have a problem, then you should be happy. :stuck_out_tongue_closed_eyes:

Good. I can quibble about some shortcomings in the UI - like not remembering that I want 100 clients shown per page, not just 10, or that it doesn’t know/show or remember as much about clients as would sometimes be useful (mainly when I have a new mac address show up and I’m not sure what it is. It doesn’t give me any manufacturer data or so) - but basically, I can say - with the limited requirements I have (I still haven’t even set up VLANs…) - it just works ever since I got it working. By that I mean: getting started wasn’t at all smooth due to some specific local conditions on my network which Omada was unable to handle.

The thing was that I didn’t buy their hardware controller since it seemed logical to me to run it in a docker container on my server. Now, if I remember correctly, that meant that the controller was inevitably running on my existing network (say: 192.168.1.xxx), but there was no setting to tell the controller which network it was running on (and in which it consequently should adopt the other network devices, especially the router, which is supposed to act as DHCP server for that network. Once we had figured out that this was what was going on, it was possible to circumvent the chain reaction of everything going wrong (i.e. the controller not being able to adopt the devices, or adopting the router which then lost access to the controller because it was adopted to a different network, or whatever it was), but what was causing immense headaches was figuring that out.

Luckily, I had really excellent support from the seller (shoutout to Arjen at the KommaGO support team): you rock!), who in turn had a line to the folks at TP-Link who actually added the possibility of configuring the controllers default network, thus removing the root cause of my troubles.

It’s difficult to say how much TP-Link are to blame for my wasted weekends. For example, I’m not sure if the problem would have been the same if I had used their hardware controller. Chances are that all Omada devices would have been adopted without problems, but on the “wrong network” (because my server and many smart home devices are using static IPs, I can’t easily change my network). I suspect that solving that problem would have been easier.

On the other hand, I think it is a design flaw to hard code the default network on which devices are supposed to run during setup. And TP-Link seems to agree, since they fixed it pretty fast. I’m not a software developer, but I think that if your aim is to build robust software, you make the default network configurable. Not because you know about certain scenarios where that can be a problem but because you understand that such scenarios inevitable exist and you want to be prepared for them. You hardcode it when you want do get the job done quickly.

So, based on that, I do give TP-Link the blame, but with all the disclaimers above. It’s a somewhat forgivable mistake at the level of prosumer or budget-enterprise (if that is a thing) product range.

The other minus was when I found out that I need mDNS do make sure that chromecast and stuffs works across VLANs and that Omada simply doesn’t support mDNS relaying across networks. That is actually the main reason why I never really got down to setting up VLANs yet: figuring out the right way of doing this is enough of a challenge, so I didn’t want to go into that challenge with an extra handicap of lacking mDNS support. But as you point out, it’s either already there or will soon be. SO maybe I’ll approach VLANs over Christmas… (Can’t think of anything better. Except maybe verifying that my duplicacy backups are still running).

Yes, I do think so. But my comparison is biased, because I never really got started with ubiquiti. I just had the dream machine for a couple of months, and kept having connectivity issues 2.4 GHz smart home devices, seeing traffic stats that made no sense, having some clients simply not showing up in the client list, and facing support who was well trained in blaming everything but the own product for what was going on and who was immune to arguments and evidence to the contrary. So I never got to a same stage with three APs and a managed switch that I now have with Omada. I think, when I bought the Omada stuff, I wanted to make sure that I wont regret switching , so I put APs all over the house. So, who knows, if I had made the same investment in Unifi, maybe everything would have been just fine?

Yes, definitely. Especially if it is true that Ubiquiti has gotten better (my experience is from two years ago).

I wouldn’t recommend Ubiquiti to anyone getting started. It’s just to obvious to me that the company is on a questionable path, regardless how attractive (some of) their products may be at a certain point in time for a certain use case. But for anyone who already invested in Ubiquiti stuff (and has a stable network that works), I don’t thing it makes sense to switch to Omada. “Never change a running system” applies here very much.

If you are impatient with Ubiquiti even though your network does what it’s supposed to do, I guess what you’re struggling is the knowledge that it doesn’t feel robust. It would make you much happier if you knew that the bits and bytes on your network are being pushed around by an engineering masterpiece. :wink:

I think they did fix it though, from both sides, including being able to access configuration locally. Which I even used once.

Your channel is awesomely symmetric – meaning it’s either DSL or fiber, or ethernet, either way cable modem not involved, and pretty high bandwidth – usually the problem is with cable modems and on the lower ends on the capacities.

I had 12/2 Mbps internet for a while (yes, I live in the middle of the Silicon Valley, and yes, that was the best internet I could get without selling the kidney), and being the backup afficionado that I am my upstream was pegged at 100% 24/7. As a result, latency would vary wildly between 40 and 3000ms. With SQM – stable 15ms. I first tried it on OpenWRT, got blown away by the result and just looked up commercial router that supported it out of the box. The list of those consisted of 1 element. USG. So that was the gateway drug into the ecosystem.

Now I got 600/20, and with SQM off I get latency spikes up to 40ms, with is not a big deal really, but with – it stays always under 20. So, no reason not to keep using it.

For testing fast.com could be useful – it’s Netflix’s speed test, that you can configure with the specified number of threads and duration – to exceed the providers’s speed boost interval. Netflix hosts their cache servers at ISPs so this actually measures your link to ISP as opposed to ISPs link to wherever the test server is located (which also can be at the ISP btw, but fast.com still allows to specify the test parameters)

No, I knew it was a problem, I just hoped it was fixed. but nope :slight_smile:

If there would be a difference – that would have been another problem. It should not matter…

Unifi solved it by having new devices reach out to the controller by the hostname “unifi” which the gateway by default assignes to the controller device. Which is great – no need to hardcode anything. I would expect tplink to do the same. Statically configuring anything seems pointless, espeicially when they provide full solution.

I solved that by not having vlans (besides cameras, that physically are outside with ethernet cables, in case, you know, criminals climb to the building with a laptop to join my network and … mmm… I don’t know, play a movie on my speakers, or print a page on my printer.

It’s also probably because there are no realistic benefits to do that at home.

I have a separate 2.4GHz SSID for 1 device. The thermostat. Everyone else is on a 5 GHz ax network.

I did not know they had support. Wasn’t their whole model that there is no marketing, no support, and you are on your own and low price.

I judge that by me needing to babysit it before and not needing to do it anymore. Even configuring ipv6 was a breeze, when my provider turned it on.

I guess you are right. I did not pay attention to it for few years, meaning it was silently doing what’s expected of it, and that’s a win; but yesterday seeing that all broken crap in the UI there is still broken is a bit disappointing… And yet, I did not feel the need to look at that broken crap for two years in the first place, so why should I worry whether it is broken or not :slight_smile:

I heard “not broken – don’t fix”, but yes, I agree.

Yes!, this precisely! Either polish the crap out of the feature, or don’t let it past the beta software. Especially if this is a gimmicky poorly thought out user facing feature, like network stats on unifi.

I guess I’ll let it be then. Thank you for the input!

Is there any area in IT in which you’re not an expert? :thinking: Yes, it’s fibre.

No, what I meant is that since their hardware controller would have been free to use any default network it wants while their software controller was trapped in the static IP of my server. The software is identical, though. At least the Linux version. They also have a Windows version, which they always release before the Linux version, which I think is kinda funny.

You either don’t have so manny smart home devices, or you went zigbee/zwave instead of wifi.

lol :slight_smile: It’s just forums is not a good indicator, because people predominantly speak when they know what they are talking about (at least, on a technical forums, reddit does not count), so it is a selection bias. In reality, the longer it goes, the more obvious it becomes that there is so much stuff to know about, let alone learn to any meaningful degree, that it’s humanly impossible to cover even a small fraction in a single lifetime. Seriously, I’ve been at my current job for 8 years, and the perceived relative amount of my knowledge is steadily declining. It’ ridiculously humbling, and some call it an impostor syndrome, but I disagree; it’s in the nature of the thing: everything is simple on the surface, if you start digging more complexity emerges, it’s a crazy fractal.

Ah, it makes sense now.

It’s a mix actually. Some (speakers) are wifi (and work on 5Ghz network, on DFS channels, which of course UniFi supports but the wifi metrics in UI does not show, and I’m no longer expecting them to fix it) and the rest (lights) – zigbee. But then since I already have a network for thermostat – any other future 2.4Ghz devices are not a problem.

Which reminds me – does Omada controller and access points support DFS?

I have actually not been able to figure that out. Or rather: it does support DFS, as shown here
Screenshot_2022-12-07_10-13-53_PM

but I nevertheless only see four 5GHz channels, and I have no idea why the others are not showing up. They are available in Sweden, so that’s not the issue.

I suspect that the two small APs don’t support those channels while the main one apparently does, based on this:

Screenshot_2022-12-07_10-57-47_PM2

But I can’t access the devices configuration page any more since I changed its IP to a fixed (reserved) IP. No idea what’s going on. When I click on any of the other APs, their settings page opens, but on that one I just get a modal saying “General error”.

Wild guess, but maybe when you click on the settings page it tries to access the configuration page by hostname, which it does not have, because DHCP handshake did not happen, because the AP did not request an IP, because you set it to static one.

Can you access configuration page by that IP directly instead?

Generally, it’s better to configure static lease on the DHCP server, if persistent IP is desired, even though most DHCP servers will issue the same IP to the same device by default, without any configuration.

This solves various DNS/hostname issues, headaches if you change the network address, etc.

Why did you have to set a static IP?

LOL, that’s what I did. I said “fixed IP” and because that is TP-Link terminology, I added “reserved” in parantheses to make sure I’m clear. I guess I should have thought of some more syonyms, like “static lease” :stuck_out_tongue_winking_eye:

1 Like

I guess I subconsciously wanted to give an excuse to Omada. But I guess if there have all the info on the AP there is no reason for it to not work.

Thinking it through now — it’s a controller, it already manages the AP, so there is no excuse, even if hostname is not available through dns

So it appears that slow releases are not because of ensuring stability but simply the dude who suggested to copy unifi got his bonus for the idea and bootstrapping the project and left, and their successor does not care much, but has to do the bare minimum to keep the project alive because it was his superior, and another higher up has vetted the project, and hasn’t left yet, according to my crystal ball.

Thinking on connection tracking in unifi with ipv6 per client – I’m not sure why do Ubiquiti give an impression that it would work: each client has multiple ipv6 addresses, some are privacy addresses, specifically designed to prevent tracking and correlation – so showing accurate traffic stats in the dashboard per client would be impossible by design, without some endpoint client that will report statistics.

They still shall be able to classify traffic though, and it is still broken.