I’ve tried using the same SSID for 2.4Ghz and 5Ghz but find that some devices (my kids’ Fire tablets, for example) end up hanging on to a weak 5Ghz connection when they would’ve been better off switching to 2.4Ghz. But if the bands have different SSIDs, I can at least easily force them to switch manually.
I've had mixed results depending on devices -- my Apple devices tend to hop between bands and APs quite excellently.
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.
Nintendo Switch wifi is the worst. Mine is places 2m next to the router and can only do around 25 mbits. All other devices I own do at least 200-500 mbits.
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.
Yeah, it takes its sweet time downloading large games. I get about 40mbps. On the upside, Switch games tend to be much smaller than their next-gen counterparts.
The key to a happy Switch life is a large micro sd card. Fortunately even 1tb are affordable now.
Agreed, I had to go wired to get any kind of decent connection, and then I'm behind CGNAT so I can't play Mario Kart 8 with it (for that game, I just use my phone as a hotspot and suffer).
Turning off Unifi Band steering was key to fixing my moonlight home streaming setup. That and disabling 2.4Ghz entirely for the network I use to stream on. Also manually picking the fastest channel by checking each one individually and testing it. Now I can stream 4k VR @ 72 hz no problem. Haven’t had to touch my router settings since doing this.
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.
This is something a good Wi-Fi controller can solve. It brutally disconnects the misbehaving device to force him to switch. There is unfortunately a lot of such devices which are very poor at hopping and hence this is a common workaround in many WiFi products, you don't even need to get something enterprise grade.
Works fine without K or R, but then the client has to do more work and lots of client devices have bad software on them. On top of that, while K and R can help, even then it needs to work with the client to have all the benefits.
I usually have the opposite issue, devices staying on (slow) 2,4 GHz directly next to the router. I would like to copy some files, and switching to 5 Ghz would vastly improve performance. But the device just doesn’t.
I solved it by just disabling 2,4 ghz and adding enough repeaters/APs so I have coverage everywhere.
Exactly. While I was using 2,4 GHz I had a lot of random issues. Probably faulty/bad WiFi devices from neighbours. Since I switched to 5 GHz they are all gone. The higher frequency is probably blocked by the walls enough, not to interfere.
I just create a dedicated 5ghz SSID and then a “mixed” SSID I can dump all the low bandwidth crap onto. All the laptops and phones live on the 5ghz and the rest can figure it out on their own.
And what's this Wifi 6 business? Am still upgrading devices to 5! Is there a new 802.11x standard? If service is (barely) 1 gig, and most end users dont notice degrading, why bother?
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 ;)
> If service is (barely) 1 gig, and most end users dont notice degrading, why bother?
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
WiFi 6 makes a big difference in congested environments, in my experience. In an urban office, clients of our WiFi 6 APs get roughly 2x throughput (~200-300mbps) than peers on 5. It's borderline impossible to saturate the uplink at max speeds for any network when there's congestion, but the improvements to client isolation are substantial IMO.
Wifi is a shared medium; just because it can keep up with your service, doesn't mean it can keep up with yours and your neighbors services. Wifi 6 brings better modulation schemes and OFDMA support, which helps with multiple devices co-existing.
Also, wifi is not just last hop to the internet. Don't you have services in your local network, like NAS?
Repeaters and meshes are generally a bad idea, repeaters specifically.
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.
Eero is set up so that Amazon can snoop your local network, and/or use it to create a shadow network to defeat IoT air gaps. I assume they do, or at least will eventually.
Look at how they've been behaving over time with Nest.
Up to 2019, Macbooks had ac 3x3 MIMO wifi. Since then, they have ax 2x2 MIMO.
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.
It's not out-of-the-box perfect, but I've had decent luck using DAWN, which targets openwrt, to get decent bandsteering. I can always ssh in (I personally havent been interested in installing/trying the "luci" web interface) & move someone between bands if I need to. My understanding is it's typically thr network nit clients that is supposed to be in charge of bandsteering & that devices hanging on to what they lock on to is the norm, typical.
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 decision is always client side, just like with roaming.
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.
In addition to band steering (which is moving between bands on the same AP), there is also Wi-Fi EasyMesh[1] which allows multiple APs to coordinate with each other (over wired or wireless backhaul) to steer STAs (clients) between APs. However, the Ubiquiti AP is not certified for EasyMesh[2].
I had a minimum rssi set for an ubiquiti access points 5ghz channel. The client would just keep reconnecting to the 5ghz channel and getting kicked immediately. I had to manually lock that device to a specific band and access point. Insanely bad software on the client and very frustrating.
I use that feature on my Dream Machine. It doesn't really help. My laptop will still hop on the wrong band or AP, or my phone will drop off if I'm in the back yard. Meh
Canon printers also can't handle 2.4 and 5 networks with the same SSID.
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.
For Eero, there is now an option to disable 5GHz for ten minutes in order to connect some troublesome devices. It might work for connecting such a printer.
Funny timing. Was helping my father in law troubleshoot his WiFi this weekend and came across this article.
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.
This is one of the main reasons I bought my own docsis 3 router for about $100 6 years ago. Comcast doesn't have access to it. The other bonus is you save a lot of money over the years by not having to rent it from Comcast, every month for the lifetime of your service. It pays for itself the first year. You give up pay per view/on-demand which never affected me, but something to consider if he uses that. I think you can still get ppv but have to call in or something and can't just order it using the remote, but my memory on that is foggy since I never use ppv. They make good Christmas presents and saving the FIL money always builds up the brownie bank :)
If you’re with Comcast, then it’s very likely they do have access to the modem, even if you own it.
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.
if he only paid 100$ for a modem and it was brand new, it likely wasn't an all-in-one station like what large ISPs are trying to push. Cheaper/dumber modems severely limit the amount of control Comcast have and how much they can fuck up your network with a bad update. They can't mess up your wifi settings if the box they control doesn't even have a wireless radio on it.
"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.).
And how do they do this? They have a team dedicated to hacking modems? More seriously, many cable modems have a setting "allow ISP to update settings". You can disable it and then the ISP cannot access it, full stop.
They can however very easily block it. Especially if they contract prohibits using your own modem.
Do you have an example of a cable modem that blocks remote setting updates?
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.
It's incredibly common to see misconceptions between modems, gateways, routers, etc. I think this confusion is exacerbated by the fact that Comcast and most other coaxial cable (even if they're fiber, if the output is coax to your unit, it's going to be coaxial for this purpose) systems.
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).
You’d think they’d have some kind of migration system to detect if there are devices on the network that are lost after the switch over and revert if so.
I don't think WPA3 is totally ready for widespread use (yet) due to older IoT devices. I'm not even totally sure what problem it solves, so I should probably read up on it.
Funny thing about WPA3: it works with all my devices (including a 12 year old think pad x201s), but only on Linux. On windows they all can’t do WPA3, because the cards are „unsupported for WPA3“.
The difference is probably in the way WPA is handled; WPA Supplicant can be made to work with any radio module that supports passing through the authentication and encryption. But Windows doesn't use WPA Supplicant and instead relies on each manufacturer to make sure their driver either has its own WPA Supplicant or uses on-chip authentication and encryption in the WiFi module itself.
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.
Only authentication will not be offloaded, actual data encryption still is.
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.
In the old days we needed a lot of tricks because firmware loading either didn't work or we didn't have the firmware binaries yet, so even (IIRC) ath9k didn't utilise on-ASIC for everything. But that was in the B (and maybe G) days.
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 bypassed WPA supplicant on Tumbleweed, and manually setup the connection.
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.
Interesting. I had the hardest time getting wpa_supplicant working on a new Debian install last weekend, and eventually gave up and switched to iwd, which was new to me, but worked immediately
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.
One negative side-effect of the same SSID policy is you might not be able to share your WiFi password by simply putting your devices close to each other. Ordinarily, Apple devices can share WiFi password easily by putting an already set up device close to a new one. But if they are momentarily connected to different networks (frequencies), even though they have the same SSID and same password, Apple software will see them (correctly) as on two different networks so the password will not be shared even when the password is the same on both networks.
I don’t know if the automatic band switching is any better than the manual one but I find this issue is quite a hassle.
>But if they are momentarily connected to different networks (frequencies), even though they have the same SSID and same password, Apple software will see them (correctly) as on two different networks so the password will not be shared even when the password is the same on both networks.
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?
One is connected and logged on. The other sees the same-named network and is not logged on yet because it doesn't know the password. Two different senses of "connected."
Multiple non-unique SSIDs (name) can exist within a single router. More extremely, you and your neighbor can have the same SSID on two different routers.
This might actually be completely fixable by borrowing the trick Bluetooth-less Wi-Fi lightbulbs use for pairing.
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.
I believe that Apple uses something similar to their "Handoff" mechanism, described in the "Apple Platform Security Guide" [1]. This uses Bluetooth Low Energy out of band paring to establish a shared key. I believe it uses the same identity keys as iMessage to establish the shared key - so you can only offer to share the WiFi password with someone you've been talking to over iMessage and you will see the name of the person you are going to share it with. Sharing the WiFi password is secure from eavesdroppers.
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.
> One negative side-effect of the same SSID policy is you might not be able to share your WiFi password by simply putting your devices close to each other.
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.
Have Apple devices become better "citizens" lately? Remember at Uni they for some time banned Apple devices, as they would mess up DHCP by reusing stale IP assignments to make it seem quicker to connect or so.
This isn’t unique to Apple, I believe Windows also does this and there is even an RFC explaining the concept.
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.
Such a ridiculous complaint, after all, it's not like there's a worldwide shortage of non-routable IPs. Just make your network address space large enough that your DHCP server is rarely, if ever, reassigning the same IP address more than once. I see so many network operators desperate to "right size" their IP ranges when they could just allocate a /18 or /16 or even larger.
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?
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.
> parent said it caused network issues at their university.
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.
You're not wrong, but I'm saddened at this attitude. IMHO the tech giants already have so much power/ability to shape/force the standards to suit their own practices. The attitude of "Apple should be able to violate the standard all they want and it should be on network operators to accommodate them" is wildly empowering to the elephant over the ant.
Lots of routers start choking when they have more than a few thousand DHCP leases.
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.
> Lots of routers start choking when they have more than a few thousand DHCP leases.
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.
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.
> Lots of routers start choking when they have more than a few thousand DHCP leases.
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.
This is an offtopic side-track/distraction, but I've been completely thrown by the masking in the screenshots and example CSV dump.
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.
don't give your 2.4GHz and 5GHz bands different names.
I purposefully did set different names for these two band. I also only gave all my devices the password for the 5GHz band. Because latency is lower on that band.
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.
I feel like the concept of using different names for each band is like the old habits where people would disable auto-speed negotiation on Ethernet. It used to cause a problem when it first came out, but all of those issues were solved long ago, and yet it has become lore for most network admins. It’s finally going away since 1Gb requires auto-speed, however I have no doubt many would still be disabling it if they could.
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.
I separate them because things often do poor band choosing and things too far from an AP are using 5ghz when they should be picking 2.4 at that range. By separating I can choose which band I want this thing based on the coverage topology. Fwiw I’ve never found band steering to work well.
Finally I also selectively put devices into 2.4 just to keep my 5 band clearer.
Ooooh. Now I wanna find out how I can fly over an area with a drone and make pictures like the example!
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.
> Make sure that your device has Location Services turned on for Wi-Fi networking, because regulations in each country or region define the Wi-Fi channels and wireless signal strength allowed there.
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 don't want to invalidate your experience, but allow me to offer an anecdata counterpoint: Wifi works perfectly on my M1 Mac Mini and has since day 1 (to the point I never bothered to wire it up), and I have location services enabled.
I wonder what other variables are in play here that make it not work for you.
It's actually really annoying that it shows a permanent Privacy Warning for disabling "Private WiFi address" you can't disable on trustworthy networks. Apple you don't know, so stop speculating, mkay.
The rest is nice though, bad configurations finally display a warning. People harden their WiFi configurations which is nice.
> It's usually best to enable every mode offered by your router, rather then a subset of those modes. All devices, including older devices, can then connect using the fastest radio mode they support. This also helps reduce interference from nearby legacy networks and devices.
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.
Airtime fairness helps a lot but if a 11b device connects, you automatically lose 1/3 of the throughput even when that device is not active. 11g can also slow down others but only a couple percent. Also, if you disable 11b rates you can have more SSID beacons (more networks) in parallel as the beacon is then transmitted at 6Mbps PSK instead of 1Mbps DSSS.
These days I just disable 2.4ghz completely since all our devices support 5ghz and we have enough (2) access points around the house to give a good signal anywhere.
That's fortunate, what usable range do you see with your 5GHz network? I find the range is pretty dismal even with a wood frame and drywall house. My AP can be right below me and the signal is only perhaps 50%
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)
Insulated walls often have foil backed insulation which is really good at blocking wifi. Even with devices the same side of the wall, the foil makes nice constructive and destructive interference patterns that mean a device that's working great can lose all signal if you move it a few inches.
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.
It’s more common in roofs than walls. but is becoming more common on both. As people continue to take house performance more seriously, more aspects are being addressed. unsurprisingly, foil reflects radiant heat gain when you’re trying to cool. maybe directly from the sun and that emitted from hot siding.
> 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.
Foil backing is normally used on polyurethane foams, and is necessary to give the panel sufficient structural rigidity during manufacture.
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 "good" reason is often that the seller can talk the buyer into a higher price for the extra "feature". It can even be higher marginally: i.e. insulation costs $0.50 to manufacture, and they can sell it for $1; adding foil costs an additional $0.15 but now they can charge $1.50. This is common, even pervasive, with consumer pricing.
WiFiMan reports -85db and 80m when 3 floors down on the opposite side of the house from 1 Ubiquiti U6 Mesh. We have a second U6 Mesh to cover this area and users roam between the two when on the second floor where we are most of the time.
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.
Another recommendation I'd add is appending "_optout_nomap" to your SSID name. That will let you opt out of both Microsoft and Google's access point data collection.
Yeah I only learned about it recently. And apparently "_nomap" _has_ to be at the end of the SSID. A weird system for something that should be opt-in anyways.
Is it actually good to have the same name for 2.4Ghz and 5Ghz SSIDs? Would devices always pick the 5Ghz if they can? I don’t want to be connected to 2.4 all the time just because it might have a marginally better signal strength and be limited to 2.4Ghz speeds.
My experience with using the same SSID for both bands is that most devices will do the right thing, pick based on signal strength and will reevaluate that choice fairly often. However, a small number of devices (normally older or cheaper devices) will often stick to a band until they have no other choice.
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.
Dropping transmission power on the APs helps a lot of clients make better roaming decisions anyway. I did it for my 2.4ghz aps and see a lot less of client barely communicating with a far away access point rather than switching.
I have that problem all the time. I have Ubiquity DreM Machine and an AP. My laptop in my office needs a solid connection for video calls. I routinely picks a "fast" 5Ghz that drops packets instead of a "slow" 2.4 Ghz that is "solid"
That must be annoying. Here is another thing you could do if tweaking the AP isn't an option. I don't have a 5Ghz wireless adapter at hand, but from what I see on my 2.4Ghz one, you should be able to set 'Wireless Mode' in the adapter settings to 802.11ac (or 802.11ax if you're that fancy :) ) to force 5Ghz. I recall having an option to simply select the preferred band on some laptop adapters, too, so you can use it, if it's available, instead.
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" :)
I’ve configured dozens of networks over the past decade to use the same SSID for both bands, and have never observed a real world issue with myriad clients. The only tweak is sometimes the 2.4GHz Tx power needs to be dropped, but it’s rare.
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.
From my experience, both Android, Linux and Windows consistently fail to use the faster 5ghz WiFi when starting out on the 2.4ghz. That's why I still have two separate SSIDs at home.
From my experience devices do a good job these days picking the better of the two options. I notice that there are quite a cases where in practice some devices get better performance by picking 2.4 than 5. In particular I have some devices that apparently learned to stay on 2.4 for longer because I move them more between the different access points than for instance my macbook.
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.
Just got fiber to the home and they gave me a free Eero (and more or less imply to the non-power users "this is what you use now")
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)
Some APs (eg Ubiquiti) can actually steer clients from one band to the other based on minimum RSSI and other parameters (including device compatibility, and you can exclude or force a band for individual devices), which prevents this from happening.
The phone will pick 5GHz when it's both needed (the phone isn't asleep) and it is actually faster than 2.4GHz. Forcing 5GHz is bad when your phone is good at roaming.
Seriously, this. I run an enterprise grade Meraki deployment (router and access point) with all the 802.11ax bells and whistles. I have 8 HomePods/minis in a ~1000 sq ft space. They can reliably play music all synced up maybe… 20% of the time? It’d be really great if Apple just provided an AP that would drive them without issues.
Probably it’s igmp snoop, which kind of a protocol violation. It’s understandable because multicast over WiFi is really a problem, especially if you’re transmitting a TV stream, but if the snoop implementation is poor or out of date you’ll end up breaking anything based on mDNS/Bonjour, so pretty much Apple build the last decade, and it’s difficult to diagnose.
If you have TV based on multicast, put it on a separate VLAN so it doesn’t end up spreading over your whole lan.
Do you happen to have any resources/tools/ideas on how to troubleshoot this? I’m having issues with mDNS sometimes just not working on a network I maintain. I can run Wireshark on two devices and see that one is sending out mDNS queries and the other isn’t receiving them at all.
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).
I've had an issue where mdns transmit would cease after X minutes uptime on windows. Nothing even shows up in Wireshark. I'm still not sure why but I'm assuming the NIC driver for windows didn't like it. Switching from wifi to ethernet fixed the problem. Switching to Linux (same machine) also fixed the problem.
Oh and it was only certain multicast udp that was affected. Regular ip broadcast still worked.
ARP is not multicast in the IGMP sense, if that doesn’t work your cabling or switches are broken or you have a serious firewall issue. But given it sometimes doesn’t work, probably hardware.
Unfortunately the only way I’ve been able to get my HomePod Minis to work reliably is to disable the 5Ghz band completely and only have 2.4 — even when they’re in the same room as the AP!
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.
Interesting to read you have issues with your HomePod Mini. Mine has been stable, however all my (7) original HomePods had constant issues connecting starting around OS 14.5 / 15. I have to imagine it's related to AirPlay 2.
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 have in my router options possibility to choose what Gz should device connect to: for example, old notebook I connect to 2.4 only. Maybe you should enable same for homepod?
The SSID should’t matter if they are on the same IP address space. Make sure your router isn’t handing out different DHCP ranges for each SSID or frequency range.
May I ask: How do the Cisco AP perform in comparison to other companies products?
Is Cisco really up to date when it comes to wireless?
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...
Does anyone have a recommended way to monitor my wifi connection on my PC or Mac over time?
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.
If you hide the SSID, your phone or laptop has to ask for that specific SSID in a probe request every time it scans for nearby networks, even when it's nowhere near your router. If you don't hide the SSID, your phone or laptop can just ask for the wildcard SSID in the probe requests, or even passively listen for the periodic beacons. That is: if you hide your SSID, not only you're announcing to everyone around you all the time your SSID, but also it doesn't hide it very well, since the SSID is still sent in plaintext in the probe request every time your devices attempt to connect to your router.
I don't see how that is any different than having a public SSID. The goal behind hiding it isn't to prevent people from knowing it, just make it less obvious.
