Not trying to defend TP-Link or anything, but I recently bought a pair of mesh router from them and they work very well.
BTW, this hidden network probably uses another protocol (for the OneMesh). It is the 802.11s (https://en.wikipedia.org/wiki/IEEE_802.11s), that uses its own encryption method based on Simultaneous Authentication of Equals (SAE) (yeah, that is the same as WPA3, however it came before it). It shows as hidden network on Wi-Fi Analyzer, but the network is not actually hidden in the same sense of a hidden Wi-Fi network: this simple happens because 802.11s has no concept of SSID.
The authentication of new devices happens when you pair a new router using the application available on Android/iOS (it has a web interface too but AFAIK it doesn't allow adding new mesh routers to the network). So it seems pretty secure for me, at least sans some security bugs that I am sure that the device should have. Doesn't bother me too much considering that most bugs that I saw on those consumer routers generally comes from the security from things like administration pages and not the Wi-Fi network itself (unless it is something like KRACK that affects all devices implementing the protocol).
Yeah, it is still pretty sh*t that they enable this by default, but if the router from the author of blog post is from one of their lines of mesh routers I do think this is kinda of made by purpose, because using multiple routers devices is kinda of the idea of a mesh network.
Thanks for the info. That makes sense given the "11s" configuration I found for those SSIDs. The router is not in their mesh line AFAIK, though most of their home products now support OneMesh, so that line is a bit blurry.
To clarify, I like TP-Link products too. Their PowerLAN products so far have been the most reliable for me and the router's been solid too. It's just really disappointing that an almost (for me) perfect product has this very simple software flaw without any solution other than to hope the manufacturer decides to fix it at some point. I had the same issue with Asus routers, but they were smart enough to open source their software and let others fix pretty much everything for them.
Just to correct myself, "11i" is actually what I saw in the configuration and it's the "Beacon Type". WiFi Analyzer shows them as 11n (2.4Hz) and 11ac (5GHz).
This type of whackery is (the primary reason) why I try to buy computing devices on which I can flash a clean OS (OpenWrt/DD-WRT for routers)[1]. It sucks because it limits my choices down to a few, but at the same time I feel like I don't throw out money at abandonware.
[1] don't even get me started on TP-Link releasing routers with the same name but v2/v3/2020/2021 update where it's hard to even know if I'm buying the one that supports the custom OS flash.
The author touched on right of repair. I’d love to see a law requiring all devices to either be supported, or if being sunset, being required by law to provide tools/source/schematics to take over the device and extend its utility beyond the manufacturer’s willingness. Particularly a last firmware that disables anything requiring phoning home to continue to function. We saw that with OnHub recently, when after only 6 years Google decided to render a lot of devices e-waste. The least they could do is recycle them for you at their own cost.
There is a specific problem with routers and certification for radio usage.
This makes right to repair harder. It's not just a legal issue. The ether is quite full and it mostly works because there are clear rules that devices must meet.
With user serviceable routers, bumping up power, or moving to locally forbidden (quieter) frequencies could become lifehacks. There was already an airport whose radio saw interference from extra powerful 5ghz wifi routers.
Locking down devices as a business model is bad. But Locking them down as a regulatory precaution to keep radio working is different.
How to keep every manufacturer from seeking excemption from right to repair under these rules would be challenging tho.
"Right of repair" being focused on hardware is a neat little trick to enforce the illusion that changing software is beyond your rights as a consumer. Yes, you can fix the antenna when it breaks, and focus on how hard the fight was to get the right to fix the hardware you own... which you don't own as long as the company uses software to control what the hardware can and cannot do. But you sure physically own those mostly-useless atoms real good!
TP-Link loves to make things proprietary. They have a custom protocol called the Tether Management Protocol, the weird OneMesh stuff noted here, custom firmware headers and signing, etc. all without proper documentation.
Many major vulns in TP-Link devices have been a result of these protocols, save for a few prolific things such as FragAttack. But hey, I guess it gives people something to hack on.
I started out buying expensive home Wi-Fi routers, and I now have a box of expensive home routers I've decommissioned because they have vulnerabilities and stopped receiving updates. Probably well over ~£1000-2000 spent on them over the past ~decade.
Next I switched to separate Router/Switch/AP and started with a Ubiquiti EdgeSwitch 8 POE, EdgeRouter Lite 3 and an AP-AC-Pro. Later I added a EdgeSwitch 24.
Recently my EdgeRouter kicked the bucket, and wanting to be entirely free from manufacturer updates so I bought a Protectli box, flashed it with Coreboot (instead of AMIBIOS) and installed pfSense. I still use the AP-AC-Pro for now but will look for more open WiFi AP options once that dies or I move from my London apartment to a bigger home.
I say "if you can afford it" because the Protectli box came in at just over £500 once RAM and SSD were added (I got the i3 model), the AP-AC-Pro is ~£120 (IIRC) and the EdgeSwitch another ~£150. This isn't "reasonably" priced equipment for home use, nor would I recommend Ubiquiti of late, but it's working well for me at the moment.
I would recommend installing Proxmox on the Protectli bare metal and running pfsense (I prefer opnsense) in a VM. Then you can run your unifi controller in a container on the same device. The i3 should be able to handle that, and you can use Proxmox to share some USB drives over NFS.
Yeah I used to get TP-Link because they were so well supported by openwrt and dd-wrt. But lately they've really become consumer hostile like with their smart plugs, removing local control functions so they can no longer be used with home automation systems :(
For WiFi I moved to unifi but they're also becoming more difficult to work with. They are making it harder to use their stuff locally without their cloud service and to use the docker controller instead of their hardware.
So when I replace it I'll have to look for yet another supplier.. Why do companies always have to turn evil.
In general, margins in hardware manufacturing are low. Companies will generally do anything they can to increase demand, and establishing a "moat" is a great way to inflate demand. "I have some stuff, but it only works with other stuff from this same company" sucks for us as buyers, but it's obviously great for the seller.
This is also why literally every company ever says that repairing anything they sell will void the warranty unless you also buy all the parts from them unless the law expressly forbids them from doing so.
You may interested in my comment below. And yes, after helping a family member set up a TP-Link mesh I will do my best not to take part in expanding their coverage again. I'm not affiliated, just a bit psyched about discovering that there exist alternatives. :)
This type of issue of OneMesh discovery could be a wifi chip firmware functionality that isn't programmable via host OS. In such a scenario, even if you could run your own host OS, it wouldn't be of much help.
Exactly. I have a nice TP-Link router that doesn't have the problem described in the article..because the first thing I did was to flash OpenWRT on it. Problem solved.
For those curious about the "Wi-Fi spam" comment: even though nothing is connected to the network and it's a hidden SSID, it still has to broadcast beacons every 100ms. The 802.11 standard says beacons must be sent at the lowest rate the AP supports, so your ~350 byte beacon at 1mbps (2.4 GHz) uses around 5% of the frequency. It doesn't take many SSIDs on the same 2.4 GHz channel to make the throughput fall through the floor. Beacon spam is one of the reasons why 2.4 GHz is practically unusable in dense environments these days.
Thankfully for 5 GHz this isn't as bad since the lowest rate is 6mbps and the signal penetrates less. Some routers have the option to disable 802.11b which raises the minimum 2.4 GHz beacon to 6mbps as well, but unless everyone does this it won't make much difference.
Another, maybe bigger, problem is probe requests. A client device, e.g. smartphone, uses "active scanning" where it sends probe packets and asks "is there any AP in this channel?" instead of "passive scanning" where it would wait for beacons. Active scanning has the advantege of being much faster. In passive scanning, client needs to stay 200-300 ms in each channel and that ads up quickly when you consider 2.4 GHz and 5 GHz channels. So clients prefer to use active scanning to quickly discover APs. Some clients send periodic probe requests even when they are connected to an AP in case they need to switch to another AP. All these probe requests together with beacons pollute 2.4 GHz.
Would there have been a better way to do design beacons? The general problem is a device needing to advertise itself for other devices to connect to, other devices which might not be capable of any faster rate...
Beacons being 350 bytes is pretty stupid though... They could have been 20 bytes long, saying "I'm a device with mac address XXX, plz contact me to know what services I have on offer".
In retrospect, definitely. But a huge part of why Wi-Fi is so successful is the wide compatibility, so we're stuck with a design that is 20+ years old. Beacons also serve to do power saving wake-ups and various other things these days, and there's room to optimize them if the Wi-Fi alliance were stricter - some vendors are broadcasting their manufacturer and model (and sometimes serial number!) every 100ms as well as lots of other unnecessary information elements.
Beacons also have to broadcast the DTIM which allows stations to come out of standby if there is data waiting for them. This can be up to 128 bytes. But I agree, beacons are stupidly fat. The basic beacon is quite small except for the additional tags. If you fire up wireshark you'll see the bulk of the bytes in broadcasting all kinds of feature nonsense that IMHO should only be broadcast during a request to join.
e.g the beacon frame is 24B on my Netgear, but the tagged paramters are 300 bytes. Sure, the SSID and DTIM are in there, but then there's a bunch of extended support rates, RSN info, HT info, and vendor specific stuff (Microsoft WMM/WME parameters, 3Com stuff... huh??)
There is out-of-band discovery for devices that support multiple bands. That should help in 6 GHz band but it looks more and more that 2.4 GHz will be only for discovery in the future..
I had a related problem with their PowerLine TPA-4220 devices yesterday. It turns out there's a DHCP server on it that you can't turn off! It's supposed to be smart and know when there's another DHCP server on the network, but it appears that this sometimes doesn't work. So I found that my laptop sometimes ends up configured on the wrong subnet, which of course kills the internet connection. The thing is, the web interface does not have a setting to shut off the rogue server.
If I hadn't done a CCNA I don't think I would have ever figured this out. I don't know what ordinary people do when this happens to them.
THANK YOU for that link, I didn’t realize that our self-hosted DHCP was facing attacks not only from the shitty ISP cable modem but also from the TP-Link APs. Hopefully an upgrade will fix that. It really says something about their attitude:
> And there seemed to be some misleading about "smart DHCP". This feature would not be enabled for no reason.
It took >2y and >100 forum posts on the issue before they even acknowledged that even in “AP mode” it silently enables a DHCP server as long as it doesn’t get a DHCP reply within 60s from boot.
THANK YOU for that link, I didn’t realize that our self-hosted DHCP was facing attacks not only from the shitty ISP cable modem bit also from the TP-Link APs. Hopefully an upgrade will fix that. It really says something about their attitude:
I had a similar experience with my Netgear Orbi; they have a dual 2.4/5 GHz network on the same SSID, but certain devices just cannot handle it (including apparently Facebook's Oculus and quite a few smart home devices).
Turns out you can split them up into separate SSIDs, but only by telnetting into your base station and each satellite and running some cryptic commands on each. It used to be possible via the web UI, but they just... dropped it.
they have a dual 2.4/5 GHz network on the same SSID, but certain devices just cannot handle it
My Canon wireless printer is one of those devices that can't handle it. If they both have different SSIDs, then it will connect fine. But if there are two with the same SSID, during setup if fails to ask the user for a password and therefore cannot connect.
Meanwhile, Amazon's eero has removed the option to have different SSIDs for each network. The two mistakes combined (Canon's and eero's) mean it's not possible to use the Canon on an eero network. Unless...
What I ended up doing was unplugging the eero, and setting up an Airport Express I used to use for traveling with the SSID I want for the eero. Hook the Canon up through the Airport. Unplug the Airport and turn the eero back on and it connects. A stupid workaround.
Yep, smart bulbs from most manufacturers need 2.4GHz. Had to go back to owning my own router (thankfully) after a brief stint with the standard Spectrum one.
Perhaps they would buy a new router, then replace other things randomly until it worked again. This approach might even be quicker. Much more wasteful however.
My TP Link wifi router loses the ability to list connected clients if you switch it to access point mode.
I discovered that this problem affects many models and people have been posting about it in the tp link forums for many years and have only received annoying "we'll look into it" customer service responses.
I will never buy a router I can't put openwrt on again.
I've been suffering this for years with a TL-WPA8630P v2.0 and so far the only solution from TP Link [1] is a firmware update that disables DHCP only until you reboot it (or the power goes out). It's ridiculous.
You can use wireshark to access the server on the device, its what they use when they update firmware, but have you used a modded powerline adaptor to access engineering settings in white goods like modern fridge freezers because alot of them have a cpu controlling everything and you access it using the mains plug?
A bit of a tangent, but I recently discovered GL.iNet[0] and ordered a couple of routers and hotspots. HK vendor for network devices running forked OpenWRT with a bunch of extras and customization.
I haven't had the time to dive deep enough into all of the code yet, but so far I'm very optimistic. Not perfect; some of the more interesting functionality (like site-to-site VPN) is tied to a proprietary closed SaaS with associated telemetry (and maybe even backdoors, intentional or otherwise). The Wireguard setup is for some reason (legacy?) not using the OpenWRT WG-interfaces but set up using custom init scripts. And getting anything else than OpenWRT/LEDE running on them with full hardware support will probably be a significant effort. I'm a bit wary of using the stock OS without compiling it myself because, well, you know.
Still, the sources are provided (including instructions on how to customize and compile your own OS/firmware). The locked-away functionality can be ported/unlocked if you're up for it. They fully support users hacking their devices all they want - and stuff like this[1] shows some hacker DNA. Out of the box the hotspot is by far the best I've found in the price-class.
The mudi's pretty cool; pocket wifi with swappable miniPCIe 4G/WiFi cards and a small dongle for Ethernet. So one could make it into a fully customized road-warrior bridge for any WiFi/Ethernet devices, or whatever other shenanigans you can imagine with that.
I really hope they steer course on the right track and don't fall to the same fate as Ubiquity. As mentioned I haven't battle-tested them extensively yet but so far I can warmly recommend them.
I just checked out their site and their offerings look underwhelming. Their top of the range home router costs $90 and supports 802.11ax... but only at 1200Mb/s. You could buy a mid-range 802.11ac router with similar speeds, made by ASUS years ago, on sale. I guess you could argue "Openwrt" is worth the premium, but ASUS routers have asus-merlin for open firmware.
I have their AX router, Flint and the CPU is actually good on this thing - ARM-A53, Quadcore 64-bit, basically it's a Raspberry PI 3. Most routers come with ARM-A7, an old 32 bit arch, and not all of them are quad-core.
When I use OpenVPN, I get over 100 Mb/s with Flint, and <30 Mb/s on ASUS RT-Ax55.
I do not think your wireless performance comparison is right, you need 3 antennas to get 1200 Mb/s on AC/Wifi 5, and there are only a couple niche desktop PCIE adapters that can do that.
I get 30-40% higher real-world wireless throughput from Flint compared to two high-end AC routers I tested. If you want to really dig into wireless performance, you would have to test real-world throughput. It certainly doesn't have all the bells and whistled of Wifi 6E and 160 Mhz channels.
Horses for courses, I guess. For my purposes, Asus-Merlin does not even come close to cutting it - and I have ran it before on a couple of different devices.
Asus routers are what's underwhelming in my experience - very unreliable and if you buy anything that's been on the market for <1-2y you never know which one will end up an expensive paper-weight down the line and which one will have decent support. The chipset vendor - avoid Broadcom - is a decent heuristic but not 100%.
YMMV but the GL-AP1300 improved throughput, coverage and reliability significantly compared to my old RT-AC66U (which is one of the Asus devices that can actually run OpenWRT without jumping through hoops).
I’ve got one of those, it’s pretty nice. Last I checked (multiple years ago) it phoned home to a .cn address by default. I don’t remember the details – please verify for yourself.
I will! Without the cloud stuff, the only thing I found so far was stuff like this, which I remove myself but is fully understandable - if you want to do zeroconf connectivity-checking on devices used in Mainland China you don't have much options otherwise. 8.8.8.8 certainly won't work.
If anyone remembers seeing an article about using a gl.inet mango as a way to mitm cellphone apps on your own network, I'd like to request a link. I read it, and bought a couple mangos a couple months later, and now, a couple years later I cannot find the page anymore.
Coming from a more remote country, that sounds completely normal when buying electronics directly from international manufacturers these days.
And, not saying anyone should do anything stupid, but sometimes these companies can be willing to send you less valuable but otherwise identical products if you ask nicely (wink wink)
Yeah, this is what I recommend to anyone who knows anything about computers. It also depends on each person's needs though, since OpenWRT sometimes excludes the latest tech.
At home we connect to a TP-Link Archer C7 running OpenWRT. It's only WiFi5, but we have zero issues streaming many 5ghz devices off of it. It's even held up fine while we both work from home.
I also run a second much older TP-Link router using stock firmware on a separate subnet. I don't think OpenWRT supports that one. But only my IoT devices and smart TV connects to it because I don't trust them on my network anyways.
All that being said, I wish there was something better and easier for the tech illiterate. The state of routers/security/privacy sucks today.
I had OpenWRT running on an Archer C7 for a while, but the wifi was "unreliable". It's like the 5Ghz would just randomly stop flowing packets. I never root caused it, but since I stopped using it my home wifi experience has been generally boring in a good way.
I live near main street in a small touristy coastal town, and there's tons of access point beacons flying around. I only have a 10,000 sq. ft. lot and have three access points to cover it. I turned off "legacy" rates everywhere I could so hopefully all my beacons are 6Mbps+ with greenfield preambles.
Different wifi chipsets cope differently with congestion. Specifically, when packet collisions do occur, some chipsets miss both frames, while other chipsets successfully decode the frame of higher signal strength as long as there's enough of a difference. In low congestion areas it doesn't matter since packets rarely collide, but in high congestion areas it can make a big difference for throughput as packet collisions occur frequently.
If you set the SSID and password identical for both bands, the clients should prefer to negotiate the optimal band. I just checked and all clients save for some legacy devices on my OpenWRT router are on 5GHz. So I'm now wondering for which cases is band-steering helpful?
I've found similar networks when inspecting other brands of router. It's not an uncommon sight these days with vendors and their 50 different proprietary mesh negotiation protocols.
While I did wonder how they generated the SSID (In this case it was 128-bit hash, underscore then the vendor name), I didn't really look too hard into it as my goal was wiping out the vendor's firmware anyway. I did spot some features like configuration sync that made my "this'll be written properly..." senses go off though.
I do note that there is a Wifi Alliance spec for this kind of thing now though. It's called Wi-Fi EasyMesh. I can't imagine anyone apart from actual SoC vendors taking the effort to implement it though, as it's a 163 page specification, available only on request or by alliance members. (Well the vast majority of chipset manufacturers are members, and the specifications have leaked anyway)
Edit: Scratch that, there were actually 3 different hidden SSIDs. The one mentioned above was a hidden IoT SSID, the other two were VendorMesh_hash and VendorMesh_WPS. :S
Readit News
BTW, this hidden network probably uses another protocol (for the OneMesh). It is the 802.11s (https://en.wikipedia.org/wiki/IEEE_802.11s), that uses its own encryption method based on Simultaneous Authentication of Equals (SAE) (yeah, that is the same as WPA3, however it came before it). It shows as hidden network on Wi-Fi Analyzer, but the network is not actually hidden in the same sense of a hidden Wi-Fi network: this simple happens because 802.11s has no concept of SSID.
The authentication of new devices happens when you pair a new router using the application available on Android/iOS (it has a web interface too but AFAIK it doesn't allow adding new mesh routers to the network). So it seems pretty secure for me, at least sans some security bugs that I am sure that the device should have. Doesn't bother me too much considering that most bugs that I saw on those consumer routers generally comes from the security from things like administration pages and not the Wi-Fi network itself (unless it is something like KRACK that affects all devices implementing the protocol).
Yeah, it is still pretty sh*t that they enable this by default, but if the router from the author of blog post is from one of their lines of mesh routers I do think this is kinda of made by purpose, because using multiple routers devices is kinda of the idea of a mesh network.
To clarify, I like TP-Link products too. Their PowerLAN products so far have been the most reliable for me and the router's been solid too. It's just really disappointing that an almost (for me) perfect product has this very simple software flaw without any solution other than to hope the manufacturer decides to fix it at some point. I had the same issue with Asus routers, but they were smart enough to open source their software and let others fix pretty much everything for them.
https://jahed.dev/2021/12/20/editing-tp-link-router-backups/
Question: do WiFi networks always send (and thereby interfere with networks in use), even if there is no traffic?
[1] don't even get me started on TP-Link releasing routers with the same name but v2/v3/2020/2021 update where it's hard to even know if I'm buying the one that supports the custom OS flash.
With user serviceable routers, bumping up power, or moving to locally forbidden (quieter) frequencies could become lifehacks. There was already an airport whose radio saw interference from extra powerful 5ghz wifi routers.
Locking down devices as a business model is bad. But Locking them down as a regulatory precaution to keep radio working is different.
How to keep every manufacturer from seeking excemption from right to repair under these rules would be challenging tho.
Many major vulns in TP-Link devices have been a result of these protocols, save for a few prolific things such as FragAttack. But hey, I guess it gives people something to hack on.
I started out buying expensive home Wi-Fi routers, and I now have a box of expensive home routers I've decommissioned because they have vulnerabilities and stopped receiving updates. Probably well over ~£1000-2000 spent on them over the past ~decade.
Next I switched to separate Router/Switch/AP and started with a Ubiquiti EdgeSwitch 8 POE, EdgeRouter Lite 3 and an AP-AC-Pro. Later I added a EdgeSwitch 24.
Recently my EdgeRouter kicked the bucket, and wanting to be entirely free from manufacturer updates so I bought a Protectli box, flashed it with Coreboot (instead of AMIBIOS) and installed pfSense. I still use the AP-AC-Pro for now but will look for more open WiFi AP options once that dies or I move from my London apartment to a bigger home.
I say "if you can afford it" because the Protectli box came in at just over £500 once RAM and SSD were added (I got the i3 model), the AP-AC-Pro is ~£120 (IIRC) and the EdgeSwitch another ~£150. This isn't "reasonably" priced equipment for home use, nor would I recommend Ubiquiti of late, but it's working well for me at the moment.
For WiFi I moved to unifi but they're also becoming more difficult to work with. They are making it harder to use their stuff locally without their cloud service and to use the docker controller instead of their hardware.
So when I replace it I'll have to look for yet another supplier.. Why do companies always have to turn evil.
This is also why literally every company ever says that repairing anything they sell will void the warranty unless you also buy all the parts from them unless the law expressly forbids them from doing so.
https://news.ycombinator.com/item?id=29642616
Thankfully for 5 GHz this isn't as bad since the lowest rate is 6mbps and the signal penetrates less. Some routers have the option to disable 802.11b which raises the minimum 2.4 GHz beacon to 6mbps as well, but unless everyone does this it won't make much difference.
Beacons being 350 bytes is pretty stupid though... They could have been 20 bytes long, saying "I'm a device with mac address XXX, plz contact me to know what services I have on offer".
e.g the beacon frame is 24B on my Netgear, but the tagged paramters are 300 bytes. Sure, the SSID and DTIM are in there, but then there's a bunch of extended support rates, RSN info, HT info, and vendor specific stuff (Microsoft WMM/WME parameters, 3Com stuff... huh??)
https://www.extremenetworks.com/extreme-networks-blog/the-of...
If I hadn't done a CCNA I don't think I would have ever figured this out. I don't know what ordinary people do when this happens to them.
> And there seemed to be some misleading about "smart DHCP". This feature would not be enabled for no reason.
It took >2y and >100 forum posts on the issue before they even acknowledged that even in “AP mode” it silently enables a DHCP server as long as it doesn’t get a DHCP reply within 60s from boot.
Turns out you can split them up into separate SSIDs, but only by telnetting into your base station and each satellite and running some cryptic commands on each. It used to be possible via the web UI, but they just... dropped it.
My Canon wireless printer is one of those devices that can't handle it. If they both have different SSIDs, then it will connect fine. But if there are two with the same SSID, during setup if fails to ask the user for a password and therefore cannot connect.
Meanwhile, Amazon's eero has removed the option to have different SSIDs for each network. The two mistakes combined (Canon's and eero's) mean it's not possible to use the Canon on an eero network. Unless...
What I ended up doing was unplugging the eero, and setting up an Airport Express I used to use for traveling with the SSID I want for the eero. Hook the Canon up through the Airport. Unplug the Airport and turn the eero back on and it connects. A stupid workaround.
I discovered that this problem affects many models and people have been posting about it in the tp link forums for many years and have only received annoying "we'll look into it" customer service responses.
I will never buy a router I can't put openwrt on again.
Cheap, good hardware and most importantly, a supported chipset.
[1] https://community.tp-link.com/en/home/forum/topic/265692
I haven't had the time to dive deep enough into all of the code yet, but so far I'm very optimistic. Not perfect; some of the more interesting functionality (like site-to-site VPN) is tied to a proprietary closed SaaS with associated telemetry (and maybe even backdoors, intentional or otherwise). The Wireguard setup is for some reason (legacy?) not using the OpenWRT WG-interfaces but set up using custom init scripts. And getting anything else than OpenWRT/LEDE running on them with full hardware support will probably be a significant effort. I'm a bit wary of using the stock OS without compiling it myself because, well, you know.
Still, the sources are provided (including instructions on how to customize and compile your own OS/firmware). The locked-away functionality can be ported/unlocked if you're up for it. They fully support users hacking their devices all they want - and stuff like this[1] shows some hacker DNA. Out of the box the hotspot is by far the best I've found in the price-class.
The mudi's pretty cool; pocket wifi with swappable miniPCIe 4G/WiFi cards and a small dongle for Ethernet. So one could make it into a fully customized road-warrior bridge for any WiFi/Ethernet devices, or whatever other shenanigans you can imagine with that.
I really hope they steer course on the right track and don't fall to the same fate as Ubiquity. As mentioned I haven't battle-tested them extensively yet but so far I can warmly recommend them.
[0]: https://www.gl-inet.com/
[1]: https://github.com/gl-inet/portal-detection
I just checked out their site and their offerings look underwhelming. Their top of the range home router costs $90 and supports 802.11ax... but only at 1200Mb/s. You could buy a mid-range 802.11ac router with similar speeds, made by ASUS years ago, on sale. I guess you could argue "Openwrt" is worth the premium, but ASUS routers have asus-merlin for open firmware.
When I use OpenVPN, I get over 100 Mb/s with Flint, and <30 Mb/s on ASUS RT-Ax55.
I do not think your wireless performance comparison is right, you need 3 antennas to get 1200 Mb/s on AC/Wifi 5, and there are only a couple niche desktop PCIE adapters that can do that.
I get 30-40% higher real-world wireless throughput from Flint compared to two high-end AC routers I tested. If you want to really dig into wireless performance, you would have to test real-world throughput. It certainly doesn't have all the bells and whistled of Wifi 6E and 160 Mhz channels.
Asus routers are what's underwhelming in my experience - very unreliable and if you buy anything that's been on the market for <1-2y you never know which one will end up an expensive paper-weight down the line and which one will have decent support. The chipset vendor - avoid Broadcom - is a decent heuristic but not 100%.
YMMV but the GL-AP1300 improved throughput, coverage and reliability significantly compared to my old RT-AC66U (which is one of the Asus devices that can actually run OpenWRT without jumping through hoops).
https://github.com/gl-inet/gli-pub/blob/326341dc5c14a256562e...
No thanks.
And, not saying anyone should do anything stupid, but sometimes these companies can be willing to send you less valuable but otherwise identical products if you ask nicely (wink wink)
TP-Link actually has quite a few(not the newest models though, but the not-newest-model should work for 95% of the customers) that runs openwrt well.
All my routers are running non-vendor firmware(e.g. openwrt) for the last 15 years, never had any troubles.
At home we connect to a TP-Link Archer C7 running OpenWRT. It's only WiFi5, but we have zero issues streaming many 5ghz devices off of it. It's even held up fine while we both work from home.
I also run a second much older TP-Link router using stock firmware on a separate subnet. I don't think OpenWRT supports that one. But only my IoT devices and smart TV connects to it because I don't trust them on my network anyways.
All that being said, I wish there was something better and easier for the tech illiterate. The state of routers/security/privacy sucks today.
I live near main street in a small touristy coastal town, and there's tons of access point beacons flying around. I only have a 10,000 sq. ft. lot and have three access points to cover it. I turned off "legacy" rates everywhere I could so hopefully all my beacons are 6Mbps+ with greenfield preambles.
Different wifi chipsets cope differently with congestion. Specifically, when packet collisions do occur, some chipsets miss both frames, while other chipsets successfully decode the frame of higher signal strength as long as there's enough of a difference. In low congestion areas it doesn't matter since packets rarely collide, but in high congestion areas it can make a big difference for throughput as packet collisions occur frequently.
https://www.crowdsupply.com/andy-haas/maxwell
Took a long time until TP-Link offered a firmware update to disable the mesh functionality. Happy to see the issue mentioned here.
While I did wonder how they generated the SSID (In this case it was 128-bit hash, underscore then the vendor name), I didn't really look too hard into it as my goal was wiping out the vendor's firmware anyway. I did spot some features like configuration sync that made my "this'll be written properly..." senses go off though.
I do note that there is a Wifi Alliance spec for this kind of thing now though. It's called Wi-Fi EasyMesh. I can't imagine anyone apart from actual SoC vendors taking the effort to implement it though, as it's a 163 page specification, available only on request or by alliance members. (Well the vast majority of chipset manufacturers are members, and the specifications have leaked anyway)
Edit: Scratch that, there were actually 3 different hidden SSIDs. The one mentioned above was a hidden IoT SSID, the other two were VendorMesh_hash and VendorMesh_WPS. :S