That seems like a different problem. The bug I was seeing was that these devices would totally stop passing traffic, not just slow/intermittent performance. ... View more

Did 27.3 fix it for you? I was surprised because the release notes made it sound like a small set of legacy devices but I saw it across 3 of the latest generation Macbook Pros, the behavior went away after the 27.3 update. ... View more

Interoperability issues with some older clients and/or drivers resulted in the clients getting into states where they could not pass any traffic (802.11ac Wave 2 MRs) Wow I thought I was going crazy. Ever since 27.2, all sorts of Apple devices have been doing this while connected to my MR42 but not my MR56.   Overall though the 27.x series seems golden if you have WiFi 6 APs. The MR56 easily got 20-25% faster aggregate throughput with my devices compared to 26.x, which is making them perform more comparably to consumer high end mesh routers like the 8x8 Orbi.   (I know in an enterprise world we might laugh at those devices, but those expensive consumer products seem to perform extremely well) ... View more

The WPA2 standard requires the PSK to be at least 8 characters, so this should be consistent across all compliant vendors (including clients), not just a Meraki specific thing. ... View more

I think going down to 2x2:2 is a pretty significant tradeoff. Sure if all of your clients are 160MHz capable, that's fine, but looking at my 75 devices currently connected, only 3 are beaconing 160MHz capability. And going down to 2x2:2 also means losing beamforming without going down to 1ss. All in all, it's a huge tradeoff on the current QCN5154 class radios to attempt to use 80p80/160MHz.   (Before you get too excited, the last time I tried this a few months ago with an AX AP that supported 160MHz, I was able to pull 1.3gbit and then my Intel AX200 would just stop passing traffic, so client side bugginess is definitely still a concern)   https://www.qualcomm.com/news/onq/2020/05/28/qualcomm-fastconnect-raising-bar-mobile-connectivity-advanced-wi-fi-6e-and     There's the Qualcomm chips that would likely be used, announced 3 weeks ago. And sorry for the 1024QAM, these chips are supporting 4096QAM. ... View more

There's zero client devices... so it might be a little early. Plus 6E's ability to use 160MHz channels more effectively means that we should really wait for radios that have better stories for 160MHz support. Currently on these chipsets, it looks like 160MHz requires splitting the 5GHz radio into 2 sub-radios, so 8x8:8 turns into 160MHz 4x4:4, and 4x4:4 turns into 2x2:2.   (It looks like the next Qualcomm Wifi 6E chips are designed for tri-band operation, and also adds 1024QAM proprietary extensions to 802.11ax) ... View more

Yeah the AX200 is so cheap and was first to market, so it's the de facto standard desktop chipset. Intel also bundles it with most of their chipsets these days so it makes almost no sense for any PC vendors to spend additional money on something included in the motherboard. Broadcom and Qualcomm all have 802.11ax client chipsets for smartphones and those are arguably higher market share already compared to the Intel AX series. ... View more

FWIW a minimum bitrate of 36 sounds too aggressive to me. Above 12 or 18 you’re going to cause severe packet loss to clients that might not have the best RF performance like a smartphone sleeping in a pocket.  Note too that loads around 30-50% are moderately high and some clients take QBSS load advertisements into consideration for roaming, so you may have a client on hand that sees a spike in channel congestion for the closest AP and makes the decision to move to another one that it believes can offer better performance because of a lower load.  ... View more

Powerline extenders can work okay, but they tend to be hit or miss. In the best scenarios I've seen maybe 10-20% of the advertised link speed (so like 100-200mbit), but for some reason in certain settings I've just had them drop out repeatedly (especially when certain appliances come on), or fail to be able to work across certain junction boxes or powerstrips too.   It's worth a shot, but honestly in a lot of sites even without line of sight, I've found a wifi based meshing solution or P2P solution to deliver better bandwidth.   I've joked that powerline extenders should just cheat and carry a dual wifi radio backhaul with internal antennas....   But in all seriousness, reliability is the big question. I've had cases where the connection quality is highly variable and it was frustrating finding any sort of pattern or explanation as to why. I've more or less sworn off the technology and I'd rather add more intermediate wifi backhaul hops to deal with this problem. ... View more

I’m actually seeing the same scanning radio behavior on MR56 — after a day or so of uptime all 5GHz neighbors disappear from the list.  ... View more

Working great on my MR45 and MR56. I love the new Performance tab -- across the whole AP it's not as useful in my opinion, but the per-client view is mind-blowingly useful. Finally if someone says "At 12PM my wifi was slow", you can dig into their client and see what AP/channel/SNR they had, correlate it with recent channel changes or DFS events, etc all from one page.   This is really where Meraki was already ahead of the competition and this is yet another leap forward. Right now I'm kind of jealous I don't work in an IT department 😄    On another note, 802.11ax performance seems slightly improved on MR56 in 27.1. On an 80MHz channel with no neighboring APs, I was previously observing around 450 down 550 up, now getting closer to 550 down 670 up (670 up is the fastest uplink I've ever seen on 80MHz HE) ... View more

This would be much better handled by the PTP bridging solutions from various other vendors. The closest you can try with Meraki is an outdoor AP and a narrow antenna but that is a poor approximation of that.   ... View more

I've got two APs in order to achieve >400mbps in each office area. That is a strict requirement for me, otherwise wifi is simply not worth the effort. Each day I transfer about 50-100GB of firmware images across 10 devices to start my work day. If they cannot get this done then I cannot start working. That's why throughput is more important than goodput for me, unfortunately, not to mention the 149-161 area has no goodput and the 36-48 channels are basically the only non-DFS usable channels. I can settle for goodput and 40MHz channels but I'd rather not when I only have 2 APs in my deployment and 80MHz performs measureably better, DFS or not. As far as DFS regulations, I am within FCC jurisdiction and I have thoroughly reviewed DFS rules for my jurisdiction and I'm not in violation. Meraki doesn't even support any channels between 5600MHz and 5650MHz, at any width, unlike some enterprise competitors that do implement the 1-24hr backoff rules. The only defined non-occupancy period for US FCC DFS channels that Meraki supports is 30 minutes (well 34 minutes including off-channel CAC time). I believe the ETSi rules are slightly more restrictive but I have APs on hand from 3 other enterprise vendors and they are all capable of automatically moving back to 80MHz DFS channels approximately 30 minutes after a DFS event. All of my clients are capable of 80MHz channel width on 5GHz. In fact half of them are capable of 160MHz but that's not practical to deploy.   Definitely please let me know if I'm in violation of any regulatory limits. I've tried my best to do my homework here and I'm even voluntarily registered with both of the nearest airports. ... View more

Correct, on 26.7 (BTW 26.7 is so much better than the older 26.x series)   I've tried both and UNII-2e tends to have more DFS events than UNII-2 but they both aren't immune from DFS.   I definitely understand the impact of 80MHz channels and 4x the DFS events. The main issue is that AutoRF doesn't seem to want to move channels in general at 80MHz -- https://documentation.meraki.com/MR/Monitoring_and_Reporting/Location_Analytics/Meraki_Auto_RF%3A__Wi-Fi_Channel_and_Power_Management   "Our tests have found that moving from one 80Mhz channel to another can cause interruptions and thus we do not change from an 80Mhz channel if clients are connected. "   This doesn't seem true in my testing (anymore?) so I am really hoping there might be a NFO for this behavior.   (For example, right now my MR56 is hanging out on 161/80 and experiencing about 20% channel utilization. Meanwhile 56 is 0% occupied, and if I manually switch to 56 it will stay there for 24-48hrs and experience much better throughput.) ... View more

Really awesome post by @MerakiDave! One more thing I'd add about some of these peculiar roaming decisions.... Apple details some of their algorithms here: https://support.apple.com/en-us/HT203068 Importantly, one thing worth mentioning is that they have a "trigger threshold", if your network strength is better than the trigger threshold, the client device is unlikely to roam unless it's being forced to via 802.11v or another mechanism. If your cells are generously overlapping, this can explain some of the behaviors of modern clients being sticky. Sure there might be an even closer AP, but the client feels its current AP is good enough that it's not worth the effort to roam. The same concepts apply to a lot of vendors but not all vendors go into technical detail about how their roaming behaviors work. Roaming behaviors also tend to be data dependent. If your client starts a Webex call and then starts walking to a different floor, the client tends to be more reluctant to attempt to roam unless the current AP's connection quality is really poor. Meanwhile if the client is idle, it might be more proactive roaming since there's no risk of user-visible wifi issues if for whatever reason roaming took longer than expected. Some of this needs to be factored into a network design and AP placement, but it's also worth just stopping to consider whether or not a distant client is actually presenting a problem or not. ... View more

If you so choose, shrinking the coverage radius (either via setting a bss minrate, reducing transmit power, or using RX-SOP) is the most natural and universal way of forcing a client to use a closer AP.   However, most clients tend to have roaming algorithms these days that will choose the most favorable AP, so you'll have to consider a few things: Is there something about the channel assignment? For example, is the nearby AP on a DFS channel and the client doesn't support DFS? Is there something in common about the client? Modern iOS/Android/Windows devices do a fairly decent job of roaming on their own Meraki APs advertise the QBSS load element correctly, which describes how busy the AP is as well as how crowded the currently selected channels are. Could your clients be realizing that the overloaded AP is undesirable and as a result be trying to spread themselves out?   How unreasonable are the far away AP associations? What kind of RSSI is the AP seeing for the clients that you think connected to the wrong AP? From the client side, most clients think APs above around an RSSI of mid-70's or better are basically equivalent. It could just be that your floorplan and AP configuration is making it look like there's a lot of usable APs from certain client locations. That's not necessarily a bad thing unless co-channel interference is getting in the way -- having that kind of resiliency is good in the event that one of your APs fails for whatever reason, you still have some overlapping coverage. ... View more

Honestly I would be totally happy with just being to get 1gbit symmetric NAT/L3 FW performance, and accept the tradeoff that the speeds are the currently quoted MX67/68 speeds if I turn on IDS, AMP, or use site to site VPN. It's understandable why the latter features require significant computational power in order to reliably push 1gbit, but 1gbit NAT is something easily achievable on the ARM chips that are used for the MX67/68 -- in fact, there are plenty of pro-sumer products that can do this.   At-home use cases for 1gbit are almost always about download speeds. It is the difference between a Windows 10 installer downloading in 2 minutes or 5 minutes. Or a Xbox video game title downloading in 10 minutes vs 20 minutes. That's something that consumers appreciate, especially when in a lot of places, fiber to the premise gigabit is being offered at a lower monthly price than 100-200mbit cable internet. ... View more

Ah, I think we are just communicating different aspects of 6GHz vs 5GHz and not disagreeing with each other! This has been a really insightful conversation.   I am curious too when Wifi 6e APs are announced, whether they will end up being tri-band or dual band (as in, whether 6GHz will be handled by an independent radio or just a single 5GHz radio will operate in both modes).   As an aside, technically these Meraki APs all use Qualcomm chips capable of their SON feature where an 8x8:8 radio can be split into two 4x4:4 radios (popularized in the consumer meshing world). I've always wondered why certain vendors have elected not to try out that approach, as I have zero 8SS products and even zero 4SS products, it seems like I might benefit more from the dual 5GHz radio approach for additional frequency domain capacity. ... View more

Perhaps I'm being dense but I'm not following how wifi 6e might be all or nothing. I expect the most capable devices will end up being tri-band both on the AP and client side.   I'm not sure why I'd want to buy a wifi enabled device that only speaks Wifi 6e and cannot connect to 5GHz or 2.4GHz...   When all are available, we end up in this situation again where there's a lot of band options and a combination of AP and client knowledge drives roaming and cell selection decisions.   Luckily we live in an era where we know a lot of tools from both sides. APs report QBSS elements to tell clients about their load and the channel utilization they see. APs can supply hints about where neighbors are. Unfortunately for clients (which I have a lot of personal experience developing), some APs do a terrible job of 802.11k reports and report APs that are no longer there or an incomplete list of neighbors.   But at any rate, there's no getting around that adding a third band with its own nuances will make things challenging. Do I connect to a 5GHz AP that's got a really strong RSSI or a moderately weak AP on 6GHz? Even to this day, we don't have a good answer to problems like that. I've got a wifi 5 AP in a bedroom and two Wifi 6 APs elsewhere and I frequently see clients make suboptimal decisions due to this heterogenous network where they could get higher throughput by switching to a different BSSID. But that is a really hard problem to solve and I don't expect it to magically go away. ... View more

I think there's an ecosystem problem still -- you'll have to wait for devices to get 6GHz when only maybe half of the smartphones on the market today even support Wifi 5. Intel's AX200/201 wifi is integrated into a lot of mobile CPUs and has no path to 6GHz (that appears to be an upcoming AX400 series per their latest Windows drivers). Most of the chipset industry is announcing brand new parts for 6GHz support... I personally will try to aggressively chase 6GHz because of the promise of a clean spectrum with wide bandwidth. But I don't think if you are deploying public wifi or other public infrastructure that will be as realistic. Sure your legacy horses won't pollute perfectly good 6GHz spectrum, but that doesn't mean we are absolved from still solving all the 5GHz problems we have today in addition to the cool 6GHz stuff. I look forward to seeing what adding one more dimension to band steering and roaming looks like. ... View more

It doesn't have to be that way. As far as I can see the MR55 and MR56 is literally just a matter of IPQ8078 vs IPQ8078v2.    Having PCIe radio modules might get us a little closer to the concept that you don't have to toss out an entire AP in order to upgrade.   If there's a new species of horse every year or a new car every year that justifies junking all the existing ones, I'm sure we would balk a bit about that.   I'm not saying I'm clutching onto my 802.11b AP, all I'm saying is that the rate of new technology between 802.11ac wave 2, 802.11ax draft, 802.11ax certified, and now Wifi 6e (and then probably .ax wave 2) is getting to the point of being very difficult to justify chasing the standard which makes it worse for everyone in terms of being relegated to APs that don't efficiently use the precious spectrum we have. ... View more

By existing you mean brand new APs and clients 😄   It might be time to bring back modular APs again, I feel it is getting really wasteful to chase after the latest wifi specs. Each generation provides meaningful benefits but it also involves throwing away a lot of perfectly good hardware that didn't change. ... View more

Hey @MerakiDave , just curious, is the 160MHz support that's coming just contiguous 160MHz channels or also 80+80 (80p80) mode too?   You're definitely right in that a 160MHz channel is rather impractical especially given how it forces you to incorporate at least 80MHz within a DFS range. I've seen some good bandwidth out of an 80p80 config but unfortunately a lot of client devices have trouble with this setup.   All in all, as others have already said, it's one of those things that sounds neat on paper, but I doubt it will go beyond just a science experiment in the real world. ... View more