Recommended settings for Wi-Fi routers and access points
support.apple.com
support.apple.com
There are ways to influence the client, which is basically what Ubiquiti is doing (and the client can ignore), and the last resort is to always kick the client once the signal is below some threshold.
Or did you mean that the GP should upgrade both their WAP AND all of the their connecting equipment?
This is normally a feature offered by enterprise or pro-consumer equipment.
On the other end, I've got a Nintendo Switch which stubbornly sticks to the first AP / band (I'm running a few APs with the same SSID/PSK) combination it grabbed onto during network setup. Even if I move completely out of range of the AP/band it grabbed onto it'll refuse to acknowledge other APs/bands until you run network setup again.
Everything else I deal with tends to be much closer to the former than the latter, thankfully. I don't use non-standard stuff like UniFi band steering, as it is known to cause issues due to non-standard behaviour.
I think the Switch is the wrong console if you want to play online. It's made for playing offline/mobile and playing with friends on split screen. And it's awesome for that.
The key to a happy Switch life is a large micro sd card. Fortunately even 1tb are affordable now.
My situation is so many nearby unique Wi-Fi networks, >160 detectable by my router alone. Lends itself to interference issues if not done perfectly.
Everyone also recommends the eero wifi mesh. But I'm hesitant. There's probably a hack to turn a jetson nano or rpi4 into a repeater ;)
Because there's really more to it than just raw bandwidth.
Either with the new protocol itself or with the new hardware that supports the protocol, you'll get other improvements besides raw bandwitdh. A WiFi 6 AP in this case should in theory provide you better security (WPA3, PMF¹), antenna design², power savings³, lower latency and lower interference⁴.
There are other improvements as well that might now be included with new AP's, but as they're not mandatory to implement it depends on the AP. Just like PMF was an optional feature with previous WiFi.
--
1 - Protected Management Frames (802.11w) simplified protection against deauth attacks. Could also mean it is enabled for WiFi 5 devices, previously a very enterprise/high-end only feature.
2 - The higher requirements of WiFi 6 will most likely mean that WiFi 5 clients will also reap some benefits. Lower packet loss, better range, actual MU-MIMO and better beamforming even individually might be a large step-up for some.
3 - Target Wake Time - scheduling better when targets wake up
4 - BSS coloring
Unless you live in a large concrete bunker, having 1 or 2 well-placed access points with wired connections is all you really have to invest in for most personal living scenarios.
Also, wifi is not just last hop to the internet. Don't you have services in your local network, like NAS?
If you have a nice wifi 5 AP, let's say Unifi nanoHD, you get better speeds with the older Macbooks (I had slightly gigabite, with 80 MHz wide channel and three streams). With the new Macbooks, you need wifi 6 AP to achieve similar performance (MCS 11, OFDM, 80 MHz wide channel, two streams); otherwise, with Wifi 5 (MSC 9) and two streams, you get theoretical 866 Mbps max.
My 2013 Thinkpad with factory WiFi card reaches 700Mbps with an higher-quality AP from approximately the same era.
Look at how they've been behaving over time with Nest.
I solved it by just disabling 2,4 ghz and adding enough repeaters/APs so I have coverage everywhere.
Also, this setup works across & steers clients between my multiple access points!
It's amazing being able to ssh in and see a map of what signals each AP sees. DAWN periodically asks clients to help map, so even if the AP's are on different bands, you can still compare what the signal would be if the node moved.
We'ee finally living in a pretty good time for open source wifi. A pity how only a couple chips have support (select MediaTek and Qualcomm) but wow things have gotten much better.
The workaround is to give a spare 2.4 router the same SSID as your real router. turn off your real router. Connect the printer to the 2.4 router so it can be configured. Then put the spare router back in storage and turn your main router on again. The printer will then connect to the 2.4 signal of the main router.
Really disappointed in Canon not being able to handle multiple SSIDs, and eero for disabling the feature of having different SSIDs for different frequencies.
All his wireless printers and his really old iPad (I think gen 1 or 2) refused to connect suddenly a couple weeks ago. No apparent changes or new devices on his network.
Turned out Comcast pushed an update to his wireless gateway that enabled ‘managed security functionality’. Part of this included forcing WPA3 security on all devices.
Once I figured out how to set it back to WPA2 for the 2.4 ghz network, all the old devices reconnected.
Good times :)
A cable modem is somewhat “trusted” from the perspective of the network: cable is physically a shared medium, and a malfunctioning or malicious devices can disrupt service for everyone on the same physical cable segment. There’s no way for an ISP to remotely cut off a bad device.
This means cable ISPs demand tight control of the equipment connected to their network, including remote configuration and firmware updates. Comcast enforce this by limiting activation to a list of approved devices, and there’s a certificate-based scheme to try and prevent spoofing an approved device.
Historically, the cable modem also enforced download and upload speed limits as well, giving ISPs another reason to keep modems under tight control, but I don’t know if that’s still the case.
If you distrust Comcast, then you should treat your DOCSIS device as hostile even if you own it, and put it behind a router you do control instead of using a combined modem/router.
"dumb" modems are a lot more reliable simply because there is nothing for them to patch inside. It doesn't have a complex OS running a wide range of services that need regular updates (managing a TV, wifi, file sharing, etc.).
I see at least one on Amazon, but it’s hard to tell if it’s refurbished, which most at that price point are.
Cable ISPs still regularly push firmware to compatible modems on their network, standalone or combo modem/router, rented or owned
If it runs on their network, they have the ability to flash it (and they do)
It's a lot less control than your wifi/router settings, obviously, but it's still a thing
They can however very easily block it. Especially if they contract prohibits using your own modem.
Both remote configuration and remote software updates are MUSTs in the DOCSIS spec[1], and my understanding is that the information in the configuration file is technically required for the modem communicate with the headend for anything more than bootstrapping. There’s no way to turn this off and have a functioning modem.
CableLabs enforces adherence to the DOCSIS spec, and there’s a certificate scheme that ensures that only certified devices gain access to the network, so I don’t see how a non-compliant device that allows users to block updates completely could ever be used with most ISPs. (I’m ignoring the possibility of extracting a valid certificate from a compliant device, of course—I’m talking about buying a non-compliant device off the shelf.)
There’s another configuration protocol, TR-069[2] which is more concerned with configuring the Wi-Fi side, and this is usually under user control in user-owned devices. This might be what you’re thinking of?
For ISP-owned DOCISS devices, even if the user switches TR-069 off, it could potentially be silently re-enabled by a remote software update.
[1] https://www.cablelabs.com/wp-content/uploads/2015/08/CM-SP-O... (section 8.2.2 and 8.2.3)
I meant the Wi-Fi settings and I did the same error as most, I wrote "modem" and meant "Wi-Fi router with built in modem".
Bottom line is, we agree, ISPs can be blocked from changing *WiFi* settings.
Comcast/Xfinity offers combination devices, which include a wireless router and a modem, in the same box. The only thing you need to connect to a coaxial broadband network is the modem. This is freely available. The only catch is that unless you buy a combo device like what Comcast gives you, you still need a wireless router if you decide to buy your own modem. You should probably do this though, because combo devices that include wireless routers tend to age poorly (thermally).
A modem will speak DOCSIS 3.1, which is a protocol that gives a lot of trust/control/authority to Comcast. They effectively can push updates to it, configure it, remotely administer it, etc. However, these are NOT functions they have if you buy your own router and connect it to the modem. If you go this route, you have full authority over your LAN and you can do whatever you please. The only thing Comcast can update is the stuff that speaks DOCSIS -- the modem.
The catch is that with the combo devices that they ship out, those devices include remote administration and firmware control for the entire stack. They can remotely push everything.
I don't like to be pedantic, but this is critical. DOCSIS 3.1 modems that aren't combination devices cost just as much as good wireless routers, if not more. So $100 isn't a good estimate of what most people would have to pay, unless they already have a router they'll use. It's going to be the cost of the modem and the cost of the router. The upshot, obviously, is that you can really spend a lot of money and go all out (e.g., buy a pfSense router, UniFi switches, access points, and a good DOCSIS 3.1 modem, and have a really nice LAN), or you can opt for a budget router instead. You get to pick one of the most important pieces of the equipment -- the router -- instead of being stuck with what Comcast gives you (probably a used/preowned combination device).
The big difference between them is that on Linux it will work, but heavy traffic will eat CPU cycles. On Windows it simply might not work at all, but when it does, and if the driver is not written by 1000 monkeys on typewriters, it can offload a lot of heavy lifting to the WiFi ASIC.
I'd say that in all cases, the WiFi chip manufacturers are to blame, but the software fallback that WPA supplicant provides should really be the lowest bar any device or OS should be able to pass.
The only exception is if your driver doesn't support management frame protection (802.11w). Then, if your AP has 11w enabled or you are using WPA3, it will use software encryption.
ath9k, ath10k, ath11k, ath9k_htc, ath6kl, brcmfmac, brcmsmac, iwlwifi, iwlegacy, mt76, mwifiex, mwl8k, rtl8xxxu, all rtl8xxxe drivers support 11w, while some others: rt2xxxpci rt2xxxusb, ipw2200, carl9170 don't.
Very interesting!
Are you using wpa_supplicant 2.9? Do not update to 2.10!
I had the same experience with 2.9, but with 2.10, I cannot connect at all, not even with WPA2 (with WPA2+3 Transitional on the AP). Downgraded back to 2.9 and it works again.
I did think it was rather odd that my WiFi AP stopped allowing my linux laptop to connect, even though it worked right before I moved from Fedora -> Tumbleweed. But even a new Fedora live ISO (I guess all Fedora ISOs are live by default) was unable to connect.
Eventually figured it was the current version of WPA Supplicant at fault, not the WiFi AP, and not the HW in my laptop. But it is somewhat annoying when something that worked just an hour ago, flatly doesn't.
2. What error messages were you seeing in wpa_cli, out of curiosity?
https://bugzilla.redhat.com/show_bug.cgi?id=2050840
Reading through the opensuse bugzilla I tried again, and it works! NetworkManager 1.38+ needed. It is interesting, that the fix is in NetworkManager (https://bugzilla.opensuse.org/show_bug.cgi?id=1195395#c47).
Checking now, I have wpa_supplicant 2.10, so I wonder how much of my problem was due to that.
iwd's been great so far - I'm no expert so maybe there are technical advantages, but I don't see any reason to go back to wpa_supplicant.
I don't get it, how is this an issue? If both devices are already connected to the same SSID, then both devices already have the password. Why would you need to share passwords?
To pair, the lightbulb's ESP8266 (or cheaper equivalent) sits with its Wi-Fi radio in monitor mode - not authenticated to anything, just watching All The Packets flying back and forth - and the smartphone sprays crafted packets to 255.255.255.255 with specific lengths (Wi-Fi encryption does not alter packet length), where the length of each packet taken in sequence then interpreted as ASCII represents the encoded setup packet containing the target SSID and password. (Of course that setup packet is plaintext and I was able to vacuum up your password *sad exploding brain* D:)
Apple could do the same basic idea here: have the connected iPhone spray a magic packet sequence to 255.255.255.255, representing say an OTP-esque nonce or similar sort of thing that is communicated to the non-connected iPhone OOB (eg Bluetooth or cellular). If the non-connected iPhone can see this sequence fly past in monitor mode, then ultimately it's on the same network even if the SSID is different.
...Or at least this all works if you can associate packet X, with length Y, *with SSID Z*. If you can't localize the sequence to an SSID without being authenticated this doesn't work.
The Bluetooth-less mechanism for WiFi only is an absolutely terrible idea and implementation. It actively leaks the network password to anyone listening. I refuse (and return) any device that requires me to connect it to my IOT network in this way. One can usually detect if this is the setup mechanism by looking at the instructions: (1) Download an App, (2) do something to the bulb (power cycles usually) (3) Setup happens automatically! I think some network stacks don't let non-privileged apps send broadcast addresses, so perhaps the scope of this damaged mechanism is limited.
It is better if the ESP8266 is put into a low power Access Point (AP) mode and configure that way - but due to this (usually) not being an encrypted WiFi session, there is also a risk of leaking the network secret unless a way to do a secure key exchange is bootstrapped in the html form or API. Both of these are possible if Javascript is enabled or via an App API. The instructions for doing this might also include downloading an App, but it also ought to require finding and connecting to a setup AP first.
I guess the best way to kill the "leak the password" mechanism is for a better mechanism to be created and incorporated into something like Tasmota or other public IOT ESP8266 codebase so it can be copied.
[1] https://help.apple.com/pdf/security/en_US/apple-platform-sec...
It seems that my experience is vastly different from yours, although I've encountered a bonkers router that separates 2.4Ghz and 5Ghz into different subnets or isolates them in such a way that only other 2.4Ghz/5Ghz devices see them so I'm not dismissing your experience completely.
Edit: found a discussion from the time https://news.ycombinator.com/item?id=2755461
Also it’s not so much that it deliberately “messes up” anything, it’s more that a DHCP server shouldn’t tell a client device that it holds an address for a certain amount of time and then either not honour it or forget that state. It’s a reasonable thing for a client to resume using an address if there is time still left on the lease and wasn’t told otherwise and the ARP collision detection mechanism is supposed to detect conflicts before it becomes an issue.
Unfortunately, DHCP implementations in the wild vary in quality considerably and the people administering them don’t necessarily understand the inner workings of DHCP all that well either, because as long as it hands out addresses, they normally don’t ever need to.
Microsoft and Apple might not be following the DHCP spec correctly, but they're breaking it for the right reasons. Offering very long lease times is one way to increase apparent network responsiveness to your end users. Give devices an IP address for weeks or even months if you can. Why not?
Often, they do compute hungry things periodically with every entry in the DHCP lease table - like for example tracking download and upload bandwidth and bytes transferred per client every second using some low performance python script.
This has become especially bad since most devices started using a new mac address for every connection. It means an apple device going in and out of range of a wifi point all night can easily create thousands of leases, all active for 7 days or whatever the default (and often unconfigurable) lease time is.
You soon run out of IP's, and even if you don't, you run into the aformentioned performance issues.
You don’t need to run DHCP services on your router. If you’re running large infrastructure, arguably, you shouldn’t, and should instead run a DHCP server on a server, and leave your router’s resources for routing.
> This has become especially bad since most devices started using a new mac address for every connection. It means an apple device going in and out of range of a wifi point all night can easily create thousands of leases
Apple MAC address privacy generates a random MAC per SSID. It doesn’t generate a new random MAC every time it reconnects to the same SSID. This would be pretty terrible as far as user experience goes too if they did.
By default, it does. That's to prevent people like McDonald's tracking your device from restaurant to restaurant as they all have the same SSID
In short, Wi-Fi scans use a randomised MAC, connections to a known network can reuse the same private MAC for up to 6 weeks, can fall back to the device MAC if all else fails.
If someone is running a network of that scale with a dinky little router that chokes at the prospect of remembering a few thousand leases, DHCP really is the least of their problems.
> an apple device going in and out of range of a wifi point all night can easily create thousands of leases, all active for 7 days or whatever the default (and often unconfigurable) lease time is.
This doesn't happen. That's not how it works.
> You soon run out of IP's
"Running out" of non-routable IPs isn't a risk, it's a choice.
parent said it caused network issues at their university.
pretty cut & dry 'why not?' included.
>Microsoft and Apple might not be following the DHCP spec correctly, but they're breaking it for the right reasons.
these groups are both large enough to influence whatever specs they need to without out-right breaking them, in many ways they're the ones least responsible in doing so, as they often times shape the specifications themselves. If they need the spec to include arbitrarily long leases let's ask them to propose that to the spec rather than being OK with certain groups violating things.
Violated specs is exactly the kind of thing that that trickles down to unintended and unexpected user experience.
No, the parent's university's apparent problem was that their DHCP was reallocating IP addresses soon after expiry. Dramatically increasing the pool size and the lease time wasn't the problem, it's the solution.
macOS wireless roaming for enterprise customers https://support.apple.com/en-us/HT206207
About wireless roaming for enterprise https://support.apple.com/en-us/HT203068
The first thing I'm distracted by in the expanded Wi-Fi menu in the first link is "Address: xx:x0:00:00:x0:00:00". wHaT wErE tHe 'x's bEfOrE?? Why mask out the first 1½ octets of the MAC when the first 3 octets are manufacturer-specific and (IIUC) would have been one of Apple's prefixes, and given that the assignment is apparently random¹ this would practically have leaked absolutely nothing. Next, the first half of the 5th octet is an 'x'. wHy??//? 𝖜𝖍𝖆𝖙 𝖉𝖔𝖊𝖘 𝖎𝖙 𝖒𝖊𝖆𝖓
Further down in the menu we have... OwO what's this™, 𝕒 🄷🄾🄻🄻🅈🅆🄾🄾🄳 𝕀ℙ 𝕒𝕕𝕕𝕣𝕖𝕤𝕤? "010.101.0.10"? Do I briefly switch to octal to parse that first octet? Pretty impressed the Mac in question is the network's router though - especially given it's a Wi-Fi network. Oh - sorry, you got a bit of sarcasm on you there, let me get it off :P
Then we have the scan window further down in the same article. OK, so the distribution of noughts and crosses :) is apparently correlated with the security setting (the protocols are all over the place and seem to represent different routers). I honestly don't get it.
Moving onto the next article, ...oh no the 'X's have gotten angry and are now in ＵＰＰＥＲＣＡＳＥ! I wonder where "01:01:00:01:XX:01" is??? "10:01:10:01:X0:10" looks positively scary.
A small tangent is required to remark about how everything that has ever happens on an iPhone happens at 09:41 really has gone so far as to be unrealistic. The original idea was just to have the marketing materials acknowledge when iPhone went live at WWDC. These screenshots with the "scan result: 09:41:45 AM" are absurd, both because iOS 11 did not exist back then, and because it would not be possible to practically do a network scan and deployment at the exact same nanosecond the OS you're supposedly supposed to be using is being debuted. The one event categorically predates the other. Hmph.
OK, moving to the bottom of this article we get the... notascreenshotsoapparentlytheartdepartmentcantseeit™ CSV data. With 𝘤𝘰𝘯𝘧𝘶𝘴𝘪𝘰𝘯 inside©! Firstly, unfortunately I don't know how to do a "this SSID and this SSID within 10km of each other" search, so I don't know if ACES and Cuba are actually real, but what I can say is that while the first listed MAC address turns out to be invalid (makes sense), the second and third entries are Apple-prefixed - which doesn't make any sense since this is supposed to be a list of access points, not client devices - but in any case, both MACs are valid and resolve to a street address - 𝔀𝓪𝓽, 𝓪𝓹𝓹𝓵𝓮? 𝓾 𝓸𝓴? - and while the second MAC only has one entry, the third has a location history that includes an address <10 meters away from the second one. Hi developer who gets around!
¹ https://apple.stackexchange.com/questions/49948/differentiat..., http://www.coffer.com/mac_find/?string=apple
don't give your 2.4GHz and 5GHz bands different names.
I cannot disable 2.4GHz band because my old WiFi printer doesn’t support the 5GHz but if it wasn’t for that I would disable it altogether.
Same with the WiFi names. If systems can’t handle auto switching to the correct band, then fix those systems. Devices can easily handle roaming between different APs with the same SSID, and this should be no different.
Edit: I do see the point of doing it if you want to control the band usage, however I think that should be a special case and not considered the “standard” way to do things for regular people.
Finally I also selectively put devices into 2.4 just to keep my 5 band clearer.
Look for the cells that contain "DFS" to see on which channels APs are required to channel hop if they believe they have heard radar.
In my personal experience, channel hopping works fine.
On a somewhat smaller, more theoretical note, I wonder what "a radar signal" is as far as a Wi-Fi SoC is concerned. Sounds like the wild-west, much-trickier-to-block counterpart to the old deauth packet attack. At least the FCC/etc can get shouty if needed...
Edit: Oh, right, it only goes offline if channel selection is manual. And presumably radar only uses the one band (?) so you couldn't flood it out or play cat and mouse.
Hmph, this is actually well designed. Given that this requires pretending to be a radar you might as well switch to a smaller pot of hot water and just get a 5.8GHz signal jammer.
That one surprised me.
I'd have expected that there would be a field in the data broadcast from the router that identified what country's or region's regulations it is operating under, and that client devices designed to handle multiple multiple countries or regions would use that to select channels and power levels that are legal there.
I also find it odd that Apple recommends this since users must disable location services on M1 mac mini systems to make the wifi work. It's just flat out broken and has been that way since they launched it.
I wonder what other variables are in play here that make it not work for you.
The rest is nice though, bad configurations finally display a warning. People harden their WiFi configurations which is nice.
Is this really the best advice? My (limited) understanding is that if a device connects with an older standard everyone gets slowed down by this. My router has a setting it calls "Airtime Fairness" that purports to combat this.
Wifi Analyzer will show the signal as coming from 30+ meters away when it is only about 4m (with multiple walls and floors in between)
I really wish insulation makers would use a different backing material - the supposed reflectivity of the foil doesn't really add much to the insulation properties anyway.
Can you elaborate on that? Seems hard to believe. There are many kinds of insulation without foil, and the foil backed variants tend to be more expensive. It's hard to imagine that we'd be making the stuff like that without a good reason.
One could use a plastic film instead though, or even corrugated cardboard.
The effectiveness of the film for insulation depends on many things.
Energy is lost through radiation, conduction and convection. At every layer of a house wall, the contribution of those effects varies widely.
Within the panel, radiation has near zero impact, because the foam material is directly in contact with the foil.
Outside the panel, the foil might have a benefit. The benefit would be maximized if there was a multi-millimeter air gap, followed by a very hot surface (Radiation doesn't scale linearly with temperature).
The foil also has a downside for insulatitive properties... The aluminium the foil is made out of conducts heat very well. That means if part of the wall is leaking some heat (for example has a nail through it), then the foil will spread that head sideways through the wall, increasing overall losses, sometimes dramatically.
The house is detached, very open plan, and doesn't have many solid walls. We also have traditional wall radiators, I imagine the lack of underfloor heating and foil insulations allows wifi to travel further between floors.
That said, a weaker 5GHz signal can sometimes still be better or more stable than a stronger 2.4GHz signal since the risk of interference in the 2.4GHz band is often much higher.
I’ve never ever had enough of an issue to worry about it.
TL;DW: Reduce 2.4Ghz AP's transmission power by approx 7db, that's the 'magic' number that should 'even' the APs out.
I must say, though, never had an issue with devices picking a wrong band so far.
[0] https://youtube.com/watch?v=JRbAqie1_AM&t=2054 (timestamp included)
I do that on Windows, but there must be something similar on Mac/Unix, too. I think these options are basically driver-related so the OS choice ultimately shouldn't matter.
edit: ah, realized I misread the post. Thought the "I picks" was "it picks" :)
Some locations I’ve had to create additional bespoke SSIDs for a specific band, but it’s only because the customer has explicitly requested it because they think it matters.
Weirdest bespoke network I have is one that only exists for an LG washing machine. It’s network stack eventually gets corrupted when network isolation isn’t enabled and receives some sort of broadcast packets.
It's awkward enough in enough situations that self-configuring wifi routers or wifi mesh devices such as "Eero" gave up forcing both bands under one SSID and now have a special trouble-shooting mode where they disable the 5Ghz SSID in order to allow you to discover / configure craptacular IoT WiFi devices. Then it re-enables 5GHz after 15 minutes and the bad device will stick on 2.4.
Despite my old situation being an absurd mess of repeaters and powerline ethernet, it's still a better experience than the Eero. I went back to the old stuff.
(ps, definitely don't want to knock Metronet. They've been GREAT so far. I've had NO troubles at all being a power user, i.e. getting Static IP and such set up)
If you have TV based on multicast, put it on a separate VLAN so it doesn’t end up spreading over your whole lan.
It’s not just mDNS though; all multicast traffic is affected (sometimes ARP doesn’t even work, and I can’t ping the other device by IP).
Oh and it was only certain multicast udp that was affected. Regular ip broadcast still worked.
Having two separate SSIDs and joining them to the 2.4GHz SSID also works, but it’s kind of a pain and you lose certain functionality if they aren’t on the same SSID as your iPhone.
I went through two different WiFi-6 networks, in every possible configuration, with no luck. Cumulatively I must have spent 20-30 hours debugging the networks, and finally happened upon something that works, albeit with caveats. I got two Eero Pro 6 access points, and disabled band steering — it was an experimental setting at the time — and everything worked! I've since re-enabled the setting and immediately have issues so I feel confident saying band steering is the issue.
Since then Eero has updated the setting to include AP switching and it's called "client steering". So, unfortunately, to have my HomePods connect I sacrifice AP handoff and have to toggle wifi if I move my laptop to the other end of the apartment.
There are quite a few folks who have brought this up in an Apple issue, and I have a friend in Tucson — where radio interference isn't an issue — with the same problem.
I just set up a "last gen" 2702i and I am still in the process of tuning it to perform as good as my modem/router/ap combi device I used before, and my experience is not really pleasant, but I could imagine that at large scale deployments there is still nothing better then Cisco and a lot of the features/setting that seem unintuitive are necessary in such cases. But yes in my case I had to go to (autonomous) firmware from 2018 to be able to use the GUI, because every newer autonomous firmware breaks the GUI, the newer ones (the newest is just some months old) all have a major bug where you can't save the changes you made and get an 404 error...
I recently started at a new company which uses google meets and I’m having an issue where my out sound and video output freeze for people communicating with me for 1 to 3 seconds.
I’ve replaced the PC and I’m still having the issue so Id like to troubleshoot the problem by ensuring my network connection is working correctly.
Hardware: replaced google home wifi mesh with top of the line eero mesh.