The known issues list doesn't look very healthy to me, especially the one regarding SSID concentrator limitations!
@cmr Yeah we won't be able to upgrade to 18.211.2 with that bug in it. Which is annoying as our firmware is now showing a warning for July 6th. And i have no desire to go on the untested 19 train.
i don't want to be the first guinea pig to try this "stable".
Is this ever going to be fixed??
"In rare cases, MX67C, MX68CW, and Z3C appliances may fail to enter into a "Ready" state despite being able to register to a cellular network and obtain an IP address for the modem."
I am in the same boat. It's incredibly frustrating that such a key feature has been broken for so many firmware versions.
Being stuck on 1616.9 and behind on security updates is very frustrating because there is no guarantee that our 4G won't function on dozens of devices in the field.
I have several MX84's which are now Legacy devices. Meraki has auto scheduled these devices to be upgraded. Since these are Legacy devices and the release notes state they will remain at 18.107.10 what changes can I expect if any?
Just security patches. No new features.
Thank you!
Hi
I am not able to upgrade from 18.211 , my options are greyed out
We are having an issue, and I wanted to see if anyone else if experiencing a similar issue: not sure if it is related.
We updated all our SD-WANs to 18.211.2 recently. We have an issue with users experiencing slow connection speeds to load webpages. After testing with packet captures, we are seeing a lot of "TCP Retransmission" "TCP Dup ACK" "TCP Out-of-order" that I am assuming is causing the slow speeds.
I will test rolling back the firmware this evening and test the packet capture again to see if it makes any difference.
Discovered this was because of an error on and upstream ISP router. Please, disregard these comments.
We are running into an issue that seemed to show up on firmware 18.211.2.
L3 firewall outbound allow rules with FQDN in destination seems to now only hit sometimes and mostly skip the allow rule.
The new Firewall Log confirms this showing it is hitting the allow only every few requests.
Does not matter if FQDN has single or multiple A records.
Anyone else seeing this as well?
We made an update from version 18.107.2 to 18.211.2 and since then the phase 1 handshake failed after the 5th packet. For additional reference there is a FortiADC Loadbalancer in front of the Meraki. We already performed a lot of different tests (different SNATs, DNAT), but what we see in Wireshark is, the first 4 packets are always correctly handled between the LB and the Meraki in a single UDP-stream. Then the 5th packet is send from the LB to the Meraki in a new UDP-stream and the Meraki is answering with an ICMP TTL exceeded packet, causing the IPsec VPN to fail. We also noticed, that when there are no active sessions on the Meraki, the first user, who is trying to establish a VPN tunnel is successful. Any additional attempts are resulting in the ICMP TTL exceeded error.
Is this a bug in this version or does it interfear with any non-optimal setting on the LB? The LB is simply configured in Layer4 mode with UDP profile and doing a SNAT. With the old software version everything runs fine without any changes on any other component. Any ideas how to further troubleshot this?
Thank you!
Regards,
Stefan