Still in progress. We are in uncharted territory right now with the global coronavirus pandemic, so we should expect responses to/from other teams that are involved to be delayed. I hope you understand. Thanks.
... View more
Update: None of our orderable 802.11ac Wave 2 (MR20, MR33, MR30H, MR42, MR52, MR53, MR42E, MR53E, MR70, MR74, MR84) or 802.11ax (WiFi-6) Access Points (MR45, MR55, MR36, MR46, MR56) are susceptible to this vulnerability. Older APs not listed above may be affected, and more updates on those SKUs will be provided soon.
... View more
Meraki is aware of the CVE-2019-15126 vulnerability (also commonly known as Kr00k). At this time, Meraki is evaluating the impact and the affected products (if any). We will provide updates as we make progress to ensure the security of our products.
... View more
Meraki WiFi-6 APs are based on the latest WiFi-6 technology. Due to this, some legacy wireless clients have issues with SSIDs broadcasted by AX APs and might fail to connect to these SSIDs even at 802.11ac or 802.11n speeds (e.g. Intel driver issue). This issue is not specific to Meraki WiFi-6 AP but rather all WiFi-6 APs from all wireless vendors. While we make every effort to support legacy devices, it might not be possible due to software/hardware limitations on the client devices. We recommend ensuring that those devices have up-to-date wireless drivers compatible with 802.11ax standard.
Alternatively (even though we strongly encouraging the first option), we can disable AX capabilities under Wireless > Radio Settings > RF Profiles > [Profile Name] > 2.4GHz radio settings:
In addition, please disable Band Steering if Dual-Band SSID is in use to ensure that those legacy clients that support 5GHz but not 802.11ax will not be pushed towards the 5GHz band.
As the WiFi-6 client adaption rate grows we expect driver-related issues to decrease.
... View more
MR Beta - Test Cases
This document contains multiple suggested features for the beta test. It is a Google document that you can download and make comments for your own records. Any questions or suggestions and additions to the form can be sent to email@example.com
Providing useful feedback & active participation
Here in beta land, we appreciate radical candor. While we hope to fulfill many wishes and to fix all the bugs and corner cases, sometimes we will be able to fix it quickly and sometimes not. The best way for you to help us and yourself is to explain the scenario and the goal to frame the issue and feedback. This allows us to understand your perspective and give us a much better insight into your feedback. The community forum we have here is meant to be a shared space for people to share ideas and issues their running into since maybe someone else has the same problem.
During the beta, we’ll be giving updates to you and following up with the community here to track progress. We want to create a great tasting experience for you and make sure we’re addressing your questions and concerns in your feedback often. If requested folks are interested enough the Product team will host a WebEx meeting.
Bug Reports - Please do not contact Meraki Support
During the beta, we encourage the posting of any bugs or issues you run into in the discussion thread. If you feel that the thread is too public in nature for your issue, please feel free to email firstname.lastname@example.org and we’ll work with you in addressing the bug, similar to how you open a Support case.
Bug reports and questions should NOT be reported to Meraki Support. The product team will be handling technical support for you. Meraki Support will not support your beta product at this time. If you open a case with Meraki Support, it should be promptly rejected and closed.
Firmware and firmware upgrades
All beta APs are running a custom firmware. In your Dashboard you will see the following:
Firmware upgrades are handled by us and do not affect any other MR access points in the same Dashboard Network.
... View more
These are the broken things we are aware of.
Issue: APs respond to active probe requests with hidden SSID values
Explanation: Basically, clients that do active probing can "see" hidden SSIDs.
Issue: APs report multiple SSIDs under Interfering APs (Wireless > RF Spectrum) at -40 dBm that are not seen by clients or non-beta APs
Issue: Local status page not loading on mesh repeaters
Description: A local status page is not there
Issue: APs are not sending LLDP packets to the upstream devices.
Description: APs only send CDP packets. Older APs send both LLDP and CDP.
Issue: APs report PoE warning
Explanation: Beta APs only need 802.3af (PoE) power. They do not require PoE+ (802.3at). However, MR45 APs do require PoE+. Since the model number for these units is not yet finalized and the Dashboard sees them as MR45 this is a false positive.
... View more
You probably have heard about WiFi 6. So what is it? Just a cool marketing buzz word or are there some real benefits for the end-users? Let's break it down!
First, the new naming system identifies Wi-Fi generations by a numerical sequence which correspond to major advancements in Wi-Fi. The numerical sequence includes:
Wi-Fi 6 to identify devices that support 802.11ax technology
Wi-Fi 5 to identify devices that support 802.11ac technology
Wi-Fi 4 to identify devices that support 802.11n technology
There are some Q&A's to get you started:
Q. What is 802.11ax?
A. The emerging IEEE 802.11ax standard is the latest step in a journey of nonstop innovation. It builds on the strengths of 802.11ac while adding flexibility and scalability that lets new and existing networks power next-generation applications.
Q. Is Wi-Fi 6 different from 802.11ax?
A. The Wi-Fi Alliance has started a campaign to use the term “Wi-Fi 6” when referring to the IEEE 802.11ax standard, indicating the sixth generation of Wi-Fi. The goal is to simplify the marketing message to better position Wi-Fi relative to the Third Generation Partnership Project (3GPP) standards used in cellular such as 5G which is the 5th Generation of 3GPP. The Wi-Fi 6 name is becoming very common now due to its simplicity. However. 802.11ax is interchangeable with Wi-Fi 6.
Q. What additional features can I expect from Wi-Fi 6?
A. Cisco, along with other vendors, has been working with the Institute of Electrical and Electronics Engineers (IEEE) on the Wi-Fi 6 standard. When ratified, Wi-Fi 6 will build on the success of 802.11ac, delivering a better experience in typical environments and more predictable performance for advanced applications such as 4K or 8K video; high-density, high-definition collaboration apps; all-wireless offices; and the Internet of Things (IoT). Wi-Fi 6 will drive Wi-Fi toward the future as the growth of wireless continues.
Q. Will Wi-Fi 6 be backward compatible with previous generations of Wi-Fi?
A. In Wi-Fi 6, all devices must also support all the mandatory 802.11a, b, g, n, and ac modes of operation. This ensures that Wi-Fi 6 Access Points (APs) and clients are backward compatible with legacy APs and clients.
Q. Will Wi-Fi 6 be allowed in all countries and regulatory domains?
A. All countries and regulatory domains that allow 802.11n and 802.11ac will also allow Wi-Fi 6.
Q. When will Wi-Fi 6 be ratified (when will the standard be finalized)?
A. The IEEE is currently scheduled to ratify the Wi-Fi 6 amendment sometime in the middle of 2020. However, the Wi-Fi Alliance already has launched Wi-Fi 6 certification on September 16, 2019. You can read what it means here.
Q. Are my current mobile/client devices that use Wi-Fi 6 supported? When will mobile devices support Wi-Fi 6?
A. There are a few mobile devices currently on the market that support Wi-Fi 6. Cisco expects that over time, the market will start to see larger numbers of mobile devices supporting Wi-Fi 6 around the second half of 2019 going into 2020. Keep in mind that you need both an access point and clients that support Wi-Fi 6 in order to realize the benefits of this new standard. You can check if your device is Wi-Fi 6 Certified here.
Key enhancements of WI-Fi 6:
MU-MIMO (multi-user, multiple input, multiple output)
With 8 x 8 MU-MIMO an AP can send data to up to 8 devices at the same time
Uplink transmissions from client devices to the AP can be supported (depends on the end device functionality)
OFDMA (Orthogonal frequency division multiple access)
Orthogonal frequency-division multiple access ( OFDMA ) is a multi-user version of the orthogonal frequency-division multiplexing (OFDM) used by Wi-Fi 5 devices. OFDMA is backward compatible with OFDM.
It allows to "split" channel into sub-channels (called Resource Units - RUs) to and use them for simultaneous low-data-rate transmissions to several devices at the same time.
Target wake time (TWT)
Clients can request a specific wake-up time when they are ready to receive data thereby conserving battery life
AP can better manage wake-up time for connected clients, thereby reducing contention and increasing airtime efficiency
With legacy standards, all devices have to wake up at the same time (DTIM)
Also supported in 2.4 GHz band
WiFI 6 device can use 1024-QAM which increases throughput for emerging, bandwidth-intensive uses by encoding more data in the same amount of spectrum
... View more
Hi MSP, "First-off, if that is the case then why has someone posted above saying that Meraki support have advised them that it is possible to restrict fail-over behaviour for VoIP traffic specifically? Is this fictional, incorrect, or could there be some confusion between Meraki engineers as to what granular control can be provided upon request?" This could be possible to do, however, it means that if the primary WAN fails, your phone will not failover (and cannot be manually failed over per my suggestions) until the primary WAN is restored. "Secondly, in our case, this situation has been triggered by two primary WAN outages in the past two months of just three minutes and seven minutes respectively. We've therefore had a Meraki support engineer extend our fail-over period at this site to ten minutes, which would only cause the site to fail over during an extended outage beyond that time-frame. Obviously we don't desperately want site internet to go down but we would certainly rather see a brief sub-ten-minute outage than an unrecoverable telephony problem that requires manual intervention." It's completely understandable. 300 seconds is a default failover interval in case of "soft" WAN failure per this KB. "Silent audio for hosted telephony systems following a WAN fail-over event is not 'expected behaviour' and you have numerous examples of users encountering and complaining about this. If the granular fail-over control to which I refer is not possible, what about some kind of software implementation for your 'fix' options 2 and 3?" It's expected behavior. As I explained, it's very likely an existing flow that was generated while being on the backup circuit. If the primary WAN circuit fails, all VoIP calls will go over the backup connection as expected, when the primary connection comes back up the MX will not cut off any existing flows over the backup circuit. SIP phones are designed to send keepalives to maintain a session with the PBX (this is to issues with NATs). Since that session remains open on the backup circuit, MX will not drop it to force the VoIP traffic over the primary circuit. Any stateful firewall should do exactly the same thing. "Meraki is a software-defined networking stack. I can't see why there would not be a way to implement a software function to force cessation of WAN2 traffic when WAN1 is restored, or prevent fail-over for certain traffic where it causes technical issues. Even if the best you can do is simply invoke a software function to simulate your point 3 to remove the WAN cable manually (really... in 2019 we're pulling cables?)." I suppose I could probably simulate this behaviour by changing the WAN parameters to something non-existent and back, but then if the other WAN connection goes down again at that exact second I'd be left with an non-contactable site (which I could place some safe money will happen under Sods Law). And yes, I consider a full reboot (which didn't actually work in our problem environment when I tried it yesterday) to be a sledgehammer to squash a fly. Especially if the Meraki is handling inter-VLAN routing at L3 to access internal resources which would be disrupted rather than 'just' internet (and the phones of course)." Rather than saying 'OK you're unhappy and it doesnt work properly with your telephone system and it causes outages that require manual intervention but it's working as intended' can you please raise a case to leverage the considerable advantages of a Cisco SD-WAN networking solution and look at 'prevention rather than cure' fix, particularly with the growing proliferation of hosted telephony." I understand that this might be inconvenient, however, this behavior is happening due to the persistent traffic from the VoIP phones and the fact that SIP provider expects VoIP traffic sourced from the Primary WAN once it's restored. MX is doing exactly what it should be doing. However, feel free to submit a feature request via "Make A Wish" button in Dashboard." Thanks,
... View more
Hi all, As I explained in my original post, there is no "fix" as this is expected behavior. I'll repost the options you have here: 1) Cut the flow that end devices are causing (unplug/reboot the phones) 2) Reboot the MX 3) Unplug the WAN2 for 5 seconds or so and plug it back in Meraki Support cannot "fix" an expected behavior. Thank you for your understanding.
... View more
Hi, mo_unify, As you said "I can see an outbound REGISTER packet going to the right IP address, but I never see the response coming back in." That looks like an upstream issue to me. Just to clarify: the behavior described in this thread is perfectly normal for any stateful firewall with a NAT table.
... View more
That's actually normal behavior for any stateful firewall, not just MX. If the primary WAN1 circuit fails, all VoIP calls will go over the backup connection (WAN2) as expected. When the primary connection comes back up the MX will not cut off any existing flows over the backup circuit since we still have NAT entries going via WAN2 due to the constant keepalives from the phones. SIP phones are designed to send keepalives to maintain a session with the PBX. Since that session remains open on the backup circuit (WAN2) the MX will not drop it to force it over the primary circuit (WAN1). Your options are: 1) Cut the flow that end devices are causing (unplug/reboot the phones) 2) Reboot the MX 3) Unplug the WAN2 for 5 seconds or so and plug it back in The main question here is why the one-way audio occurs. I suspect that PBX tries to send return traffic over WAN1 and that traffic, of course, dropped by your MX since we originate the traffic from WAN2. You should take the captures on MX WAN1 and WAN2 to figure this out and, possibly, talk to your SIP provider. Feel free to contact Meraki Support if you still running into this issue. HTH
... View more