The simple way to get round it is to count the unique mac in    dashboard.wireless.getNetworkWirelessClientsConnectionStats( network_id )     ... View more

But they are people are using the network? This is why it seems odd clients have transferred GBs over the last few days  ... View more

No, we have 70,000+ clients so not possible to ensure every things i upgrades or that manufactures have drivers to support it. So we disabled 802.11v on the networks. If you have a good AP placement design it should take into account client density and if you also then set the MDR and roaming setting to encourage clients to move to the best AP (ie don't leave MDR at 1 or 6) clients should be distributed evenly across them.    I think this is one of those areas where a plug n play solution like meraki falls down a bit compared to something like cisco aironet where you can tune how 802.11v operates and how aggressive it is.    Our view is that if without load balancing turned on we have a resonaly distribution of client to AP then we dont worry  ... View more

This is typical symptoms, they are roaming but not due to signal, with 29.4 clients are actively "pushed" by the AP. The event log does not show it correctly as it shows the client both connected to the new and old AP for a time due to the clients not cleanly roaming. Sites with high client density and or over lapping AP's are more likely to see it happening than smaller sites with lower density.    Check out "Client Balancing Behaviour - MR 29.X and Newer Firmware" from the following meraki doc. which is where 802.11v was enabled.    https://documentation.meraki.com/MR/Other_Topics/Client_Balancing   In brief now the AP tries to tell the client to move to a new AP to better balance clients across AP's, before this never happened with a active connection. in passive load balancing the AP delays allowing the Client to associate with a highly utilised AP in the hope it will associated with a different one with less clients.    post release 29.x once associated the AP send a list of potential better AP to the client in the "hope" it will move across (its always client that makes the decision) if you have a client with NIC / drivers that always "listens" to the AP it will try to switch over. This normal would not have a negitive impact if    1. The client authenticates with out issue or delay 2. the new AP does not immediately tell the client to move back.    From out experience in some offices how 802.11v has been applied, AP density, utilisation and client density  means some client  will constantly move between AP even when stationary every few minutes.    Again not an issue in it self, but of you have any compounding issues with authentication or association being delayed users are going to notice it and it will have negative effect on performance.    Also yes we do have a case with meraki, it has been escalated and while we have resolve our issues we are still working with them to provide some more detailed captures and logs for them to look in to.  ... View more

That depends what you are doing.    For example if you have  visitor / guest flow with a captive portal then you need CoA to reset the session after the user has signed on, but this is only normally used with MAB and the long auth inssue down not seem to affect this.    Also if you are using profiling in ISE and you want a way for ISE to instruct the AP to force clients to reauth you need to use CoA.    but if you just doing straight 802.1x auth to a radius server it wont make any difference to disable it.      ... View more

After disabling 802.11r, 802.11W and load balancing we saw a lots less. But I believe this is because prior to 29.5 load balancing only happens during associating, where as post 29.5 it active while clients are connected. So we have left load balancing disabled so we still see clients roam when they need to, but significantly less than when it was enabled. The new software seems really aggressive when it is enabled.    One other thing we seemed to notice is the CoA issues seemed to affect clients authenticating with EAP-TLS more than PEAP. Talking to meraki support there were saying when CoA is enabled the client always needs to go through a full auth process when it roams, and every packet must be seen before it can continue.    What we took from this is you can't at the moment use CoA on a WLAN using enterprise (802.1x) for authentication as the results are unpredictable. In most cases this will not be an issue.    For us this seemed to be a combination of 3 factors    1. 29.5 introduces active load balancing where when clients are already connected it will attempt to "encourage" them to move to better AP's. This can be remediated to an extent by disabling load balancing on the WLAN to return it to pre 29.5 behaviour.  2. CoA can cause long authentication delays so if you don't need it disable it, partially on WLAN using 802.1x based authentication. I think this was always a problem we had in the background, but the aggressive roaming caused by 29.5 highlighted it.  3. Lastly when the client roamed due to load balancing it was not cleanly disassociating from the old AP and this is where the "excessive frame loss" error comes from. looking at the logs you see the client connect to the new AP and then a few minutes later a error from excessive frame loss and getting disassociated from the original AP. This seems to happen when it roams due to load balancing.I don't know if this has any thing to do with the issue if meraki is seeing the client associated with the old AP when attempting authentication to the new one?    Another issue we found it the lack of ability with Meraki hardware to troubleshoot this, we were asked to capture packets but for this required a linux based device or setting up a "spare" meraki AP to capture packets over the air.  In the end we deployed some cisco aironet AP in sniffer mode to do it.    Thankfully our company is large enough we have spare AP's that we can set up a LAB with or deploy for testing, but without this the logs and data we could get from meraki was very limited. And even after uploading over the air packet captures to Meraki support in the end it came down to working it out ourselves. I think over the few months we were looking at this i spoke to 4 or 5 meraki engineers and each time had to start from scratch explaining it and being told the same basic troubleshooting steps made for a very frustrating experience.  ... View more

This has the same issue there needs to be something to capture the hooks, store the data and then create a report at the end of the week / month. And this is what i am trying to avoid we have a number of tools that check AP status and so i could for example use a call to Solarwind to get the AP up / down time. But i was curious if there was a way to do native in meraki.   And it looks like you can do it using the network alerts history and network devices.    results = dashboard.networks.getNetworkAlertsHistory(net["id"], perPage = 1000, total_pages='all')     for net in networks: results = dashboard.networks.getNetworkAlertsHistory(net["id"], perPage = 1000, total_pages='all') print (results) deviceevent = (event for event in results if event["device"]["serial"] == "xxxxxxxxxx") for event in deviceevent: print (f' Time start {event["occurredAt"]} type {event["alertType"]}') print   gives the events for an AP and only needs 2 calls per network. Then it's not too hard to loop through this and for a specified time range count the down time per AP.    Time start 2023-02-13T10:05:24Z type An access point came up Time start 2023-02-10T23:25:20Z type An access point went down Time start 2023-02-05T17:07:55Z type An access point came up Time start 2023-02-01T00:21:30Z type An access point went down ... View more

I thought of that but that defeats the purpose of running a single vendor agnostic monthly reporting scrip (Actually running weekly and combining) for all our separate wireless deployments. As the meraki dashboard shows the AP connectivity history of the AP it must be stored with in the data meraki hold so it would be nice to get to it via API. I was going to look at the events as I think they also have AP up/down so maybe can parse this and count the status changes and time stamps.    I might see if this data is in DNA as we also monitor the Meraki AP's in that.      ... View more

This is a nice little series, one thing I did as I got in to it was create an example script of ways to filter and search the responses.   Like, this will create a new list from the response  where the key "AP" = WAP1, that you may want to loop though and use to search a different response. subtest = [r for r in ls_dict if (r["AP"] == "WAP1")] and This will just count for you how many entries there are based on a search.  number_off = len([r for r in ls_dict if (r["clientMac"] == "FFFFFFFF")])   How about one last leg of the journy to give some examples like this to help people getting in to Python / API / JSON to take the journy to the next level.  May be sourced from the community, not lengthy code but single line well described examples that carry out specific by common operations.    ... View more

Sorry I resolved it, needed to move the looping though networks out side the "try" as it was failing on one network and ending the loop, using "try" after the "for net in networks:" and it works as expected ... View more

We have noticed a few things.    1. Upgrading to 29.x introduces a lot of aggressive roaming due to the load balancing. 802.11v.    2. If you look a lot of the frame loss is actuly aginst the "old AP" the client roams.from.AP 1 to AP 2. And then a short while later AP 1 reports frame loss and disconnect the client. So it is were the client has not gratefully disconnected from.the original.AP.    This is not all of the frame loss but if you filter a single client you will see association to new AP often come before frame loss to old.    What ever is causing the increased roaming it is a nightmare. We see clients with good strength and SNR roaming while the user is sitting still interrupting calls.    And visibility in the timeouts / thresholds and visibility to trouble shoot is not good.  ... View more

Cheer I have got a responce back and Engineer so sorting it out.    I think it would be nice if we could "tag" these Default routes and have them exempt from unique checking our selves. or chose to validate agsint either or both  "assigned subnets" and / or "routes".   Becasue the validation is useful but this method in networking of using supernet routes for summarising is common. We use it in all out hub sites to route all private IP's back to the core.    ... View more