Has MS firmware also bifurcated between different models?   The MR view is trying to say that 26.8.1 is stable for the Wifi 6 APs as the 26.8.1 release specifically has bugfixes for those APs, while 26.6.1 is stable for all previous APs. ... View more

This is surely an iOS bug. I don't think WPA TKIP / WPA2 / WPA3 is even a legal transition mode. I don't see any sign that 27.3 is broadcasting a network like that -- might be worth packet capturing a few beacons. ... View more

About 1/3 of my clients are AX — iPhones, 2020 iPad Pros, and Intel Ax200/201s.  ... View more

Endpoint AV and gateway security are complementary technologies, they are two layers of defense, not meant to substitute for each other.   As an example:   You need an endpoint AV because it’s easy to hide traffic from a network gateway. For example, if a virus uses a password protected ZIP file (or encryption) to download its payload, or even HTTPS , a gateway cannot detect that threat, but an endpoint AV can easily see the infected file as it’s being unpacked.   And an endpoint AV is potentially weak because a virus running on the endpoint can attempt to disable the endpoint AV, but because such a virus does not compromise your MX, it cannot disable protection on the MX. ... View more

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

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

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