Firmware MR 31.1.7

[Mongggii]

Hi! Is there anyone experiencing loss connection on this firmware? MR 31.1.7 since its been updated to this firmware there is a loss connection

[cmr]

I'm using it reliably.

What AP models do you have problems with?

Any particular client types?

[Mongggii]

We are currently using a Meraki MR36 for the AP.

Right now we replace it temporary for a different brand.

Since it been updated we can't connect to the internet. LED emitting a blinking blue green light. 

It been unstable since the updated firmware. 

[cmr]

What I'd do id plug it into a port that will give it an IP address via DHCP and then reset it using the pinhole on the back by the rj45 jack.

[cmr]

I'm using MR55, MR56 from the same generation as the MR36 and others from newer generations.

On a side note the MR55 is stuck here, being unsupported by the r32 software train ☹️

[TBHPTL]

Blinking blue green is not a valid LED signal....

https://documentation.meraki.com/MR/MR_Installation_Guides/MR36_Installation_Guide

if going blue then green then blue then green that could indicate a client joining and getting deauthed.  MFP something could be issuing deaths to your clients.

I would make sure the wired connection is good, check it with a laptop and pinhole factory reset the AP and let it update.  You can always check the local status page of the device.  

https://documentation.meraki.com/General_Administration/Tools_and_Troubleshooting/Using_the_Cisco_Me...

Still not working open a ticket and let support guide you and then RMA if its not working.

[Mongggii]

Hi!

Thanks for this.

Actually, I checked again and its steady on blue light. Which I think the firmware is updating and is successfully updated. 

However, our end user can't connect and its been unstable even we can connect to it after the update. We check all the wired connections and all working. We also reset the AP but the problem still occurs. That's why for the meantime we replace it to another brand since its been affecting our employees productivity. 

[cmr]

Steady blue light means that at least one client is connected to the AP.  When you say it has been unstable when you can connect, what are the issues?

[Mongggii]

So its kinda like this. 

[cmr]

Your SSID appears to be using NAT mode, or perhaps you are just using the 10.10.n.n network.  Are these public users, or corporate users?

[jvulto]

Same issue here. Just upgraded to release candidate 37.1.7.1 and checking if we speak if issues are solved. The issue only relates to my MacBook, iPhone wifi connectivity does not seem to suffer when experiencing MacBook connectivity issues. For now (just 10 minutes) problems seem te be solved.

[BaskaranGanesan]

Check the connection logs and roaming in the Meraki Dashboard. The user is connected to 2.4 or 5 GHz. Recently, I upgraded to 37.1.7.1, and I didn't feel any disconnect with the user.  

[vagrant]

I have not had any issues. 

[HeinDeLange]

We have a network that upgraded yesterday.  our 9162 went fine, but the bulk of the network is 9163E and they all kept on flapping for the day causing very intermittent connectivity like explained here..  Trying a rollback now.

[cmr]

What did you upgrade from, I'm running 31.1.7 on my CW9163Es without issue, I upgraded from the previous minor release.

[HeinDeLange]

31.1.5.  TAC confirmed that there was a bug related to available channels in South Africa and will be addressing this.  They mentioned that this bug is not an issue should we wish to upgrade to MR32.

[JNIVIA]

I have been experiencing something similar, in my infrastructure we manage 6 access point MR46 with firmware version MR 31.1.7.1 and we have had many WiFi connection problems, we have had slowness, random disconnections of the network for brief seconds or minutes generating discomfort in end users, even when the equipment is fixed without moving and with an AP about 3 meters away the equipment is roaming to an AP much further away from the one that is within reach. We talked to Meraki support but they do not give us a clear solution, they indicate that it may be the power of the AP, channel saturation among other things, all these recommendations have been adjusted to what they have indicated but the failures continue, users continue to experience momentary network crashes and slowness at times. We have also updated all the drivers of the users' machines without success, it is a constant chaos on a daily basis, the network may be stable for a few hours but after a while we receive notifications from users indicating network crashes or momentary disconnections, we do not really know what may be the fault itself. Any comments for a solution in this post will be welcome.

[cmr]

@JNIVIA I have a site with HPE Aruba APs thS that's the exact same issue as you describe above.  Static devices behaving perfectly well and then when it gets busier, suddenly deciding to roam around to less good further away APs.  I believe it is due to there being too high a density of APs with too high a power level.  I'm working on reducing the power levels to see if it improves the situation.  Another factor is that the APs are behind plastered and decorated ceilings which does seem to make their signal patterns somewhat less even.  I'll let you know how I get on as I thought it was an Aruba problem, but seems like we both have a similar issue!

[jd_1000]

Having the same performance issues, random drops in network connectivity, poor performance with PING drops and extended latencies

Reply from 10.72.8.1: bytes=32 time=103ms TTL=254
Reply from 10.72.8.1: bytes=32 time=73ms TTL=254
Reply from 10.72.8.1: bytes=32 time=946ms TTL=254
Reply from 10.72.8.1: bytes=32 time=611ms TTL=254
Request timed out.
Reply from 10.72.8.1: bytes=32 time=1299ms TTL=254
Reply from 10.72.8.1: bytes=32 time=373ms TTL=254
Reply from 10.72.8.1: bytes=32 time=13ms TTL=254
Reply from 10.72.8.1: bytes=32 time=12ms TTL=254
Reply from 10.72.8.1: bytes=32 time=6ms TTL=254
Reply from 10.72.8.1: bytes=32 time=74ms TTL=254
Reply from 10.72.8.1: bytes=32 time=5ms TTL=254
Reply from 10.72.8.1: bytes=32 time=16ms TTL=254
Reply from 10.72.8.1: bytes=32 time=590ms TTL=254
Reply from 10.72.8.1: bytes=32 time=1171ms TTL=254

Running the latest 31.1.8 having logged a recent ticket with Meraki support, inconclusive as to the root-cause.

[jvulto]

Do you have issues while using a completely disconnected laptop? That is, no USB hubs, no external displays, no Bluetooth devices etcetera. 

[jd_1000]

i've not tested, laptop only - will do that.

However, switching to a replica SSID (RADIUS AUTH) and another SSID using Meraki DHCP similar issues are not experienced, only on this affected SSID - this is the main corporate one, so used by all users.

[jd_1000]

no specific improvement

Reply from 10.100.3.1: bytes=32 time=8ms TTL=255
Reply from 10.100.3.1: bytes=32 time=23ms TTL=255
Reply from 10.100.3.1: bytes=32 time=7ms TTL=255
Reply from 10.100.3.1: bytes=32 time=7ms TTL=255
Reply from 10.100.3.1: bytes=32 time=7ms TTL=255
Reply from 10.100.3.1: bytes=32 time=8ms TTL=255
Reply from 10.100.3.1: bytes=32 time=29ms TTL=255
Reply from 10.100.3.1: bytes=32 time=44ms TTL=255
Reply from 10.100.3.1: bytes=32 time=34ms TTL=255
Reply from 10.100.3.1: bytes=32 time=55ms TTL=255
Reply from 10.100.3.1: bytes=32 time=46ms TTL=255
Reply from 10.100.3.1: bytes=32 time=6ms TTL=255
Reply from 10.100.3.1: bytes=32 time=5ms TTL=255
Reply from 10.100.3.1: bytes=32 time=6ms TTL=255
Reply from 10.100.3.1: bytes=32 time=5ms TTL=255


its very sporadic and can affect individual people at random.

INGRES/EGRESS on the internet is fine, bandwidth a plenty and no bottle necks seen on uplinks from AP to Meraki 9300L switch and onward to the interface were the Internet is plugged in:-

Access layer >> CORE >>  WAN >> 500Mb Internet

[jvulto]

Issue solved here! Replaced AP MR18 which was suspected by Meraki support engineer.

Then still issues popped-up. I started searching specifically for WiFi issues and MacBook and found the issue. Connecting certain HDMI (or other peripherals) can cause interference with the WiFi antenna/signal of the MacBook. A time consuming lessons learned: Test your device without anything connected to mitigate cabling interference.