Meraki

sungod · ‎Oct 27 2023

@TonyC thanks for the update. The option to disable would be a solution as no one I've spoken to so far in our customers (we're an MSP) realises this is accessible to their read-only users.

sungod · ‎Oct 26 2023

Yes I noticed this new a page a few days ago, it's handy to have things consolidated this way. I'd hoped it was also a sign of having API keys that are bound to the organization rather than admin user identity, but found it was still just the 'personal' admin keys it handles. Or is it a hint that we may be getting org-keys soon... 😀

sungod · ‎Oct 26 2023

It does seem logical that it should allow updating a template network. If the call does not fail because the network ID is a template, then it should report fail if it did not update the SSID. But if it says it completed successfully, that is incorrect because the SSID was not changed, there is a contradiction here. I had a look at overall documentation, but it doesn't say if a template network is treated the same as a network when making updates. It won't get you out of our current situation, but you could open a support case to report that it doesn't work. Either it's a bug or the documentation needs to clarify things, but it should not be necessary to guess!

sungod · ‎Oct 26 2023

Well, I've exhausted options with Meraki support and their security vulnerability reporting process. A read-only user has the ability to carry out a denial of service, Meraki position (stated via both channels) is that it is 'intended behaviour'. Time to warn customers.

sungod · ‎Oct 25 2023

If a feature or other entity is not available, the API will often return some kind of 4xx error. Like trying to do a MX call on an SM network. One way of handling is to catch the error and check if the message is the one you mention, then skip the org. Look at Python exception handling, for example... https://realpython.com/python-exceptions/ To avoid the error in the first place, you need to ensure the request is valid in the context you make it, you could do this by getting the org licences first, using... https://developer.cisco.com/meraki/api-v1/get-organization-licenses/ ...then checking that the licence type is correct, if not then skip the org.

sungod · ‎Oct 25 2023

I haven't tried it, but @RaphaelL comment below looks like it may be the way

sungod · ‎Oct 25 2023

I think you can only get PSU status from devices that have swappable PSU modules like the larger MR and MX devices. This gets it for you org-wide... https://developer.cisco.com/meraki/api-v1/get-organization-devices-power-modules-statuses-by-device/ But it's not in-depth details.

sungod · ‎Oct 20 2023

I'm just getting the runaround from support now, it is exactly why I did not want to open a case!

sungod · ‎Oct 19 2023

Fwiw I've been ok since Tuesday.

sungod · ‎Oct 18 2023

Well, I just reported it as a vulnerability via Meraki's chosen route (bugcrowd), will see what happens. Our internal security/systems people can decide what to do next with customers, I've more fun things I want to spend time on 🙂

sungod · ‎Oct 18 2023

As expected, support say it's supposed to work like this, disappointing. My response was that it's still incorrect behaviour and needs fixing, I asked them to escalate it. Might be useful if a few more people could open a case for this, as it stands a malicious RO user with a bit of scripting knowledge could easily cause major problems across an organization. We now have internal discussion to decide if/when we should start warning customers of the risk, as some of them want to have a lot of RO users.

sungod · ‎Oct 18 2023

@PhilipDAth I tend to follow old-school defensive programming practices... There are API calls that return elements with a None value when they really shouldn't, or that change behaviour without notice, or that give the same data with different element names for no apparent reason. Anything I need to rely on, I code to validate each element and then follow the rules to build the parameter list for the write operation. It's more effort, but still a lot easier than paper coding pads and opcode tables. I know if I trust what an API response provides, there is a higher likelihood something will break, probably at 0200 on a Saturday.

sungod · ‎Oct 17 2023

'strewth! Words fail me.

sungod · ‎Oct 17 2023

Thanks for checking. Guess I'll be opening yet another support case!

sungod · ‎Oct 17 2023

One of our customers contacted me after they had an issue with a switch port/connected device. I was surprised when they told me they had cycled the port, they have only organization read access, they do not have any other permissions such as port management privileges. I can see in the event log that the port was cycled a few times. Is it really correct that a read-only admin can cycle ports? I would not expect read-only access to permit any impact on device operation.

sungod · ‎Oct 17 2023

Meraki support claim that it is correct for multiple identical client records to be returned and want to close the case.

sungod · ‎Oct 17 2023

I opened case 10959729 it identifies an org where the problem occurs and also IDs of one of the networks/clients showing duplicates (there are many more).

sungod · ‎Oct 13 2023

This was my suspicion, but I don't have any orgs with such a short timeout set. If it's not fixed soon I'll be trying a script to keep refreshing pages to keep me logged in.

sungod · ‎Oct 13 2023

We've had the same, one of the guys opened a case yesterday. So far today I've not been logged out... Edit, just logged me out, session seemed to last longer than yesterday though

sungod · ‎Oct 10 2023

I already have several cases open on other API issues, some open for a long time now. As this endpoint is only just GA after a pretty short beta period, I would like Meraki to own it and look at the problem without me needing to open yet another case.

sungod · ‎Oct 8 2023

I was doing some testing and notice a problem with one of these new endpoints... https://community.meraki.com/t5/API-Early-Access-Discussions/Now-in-beta-wireless-packet-loss-statistics/td-p/210204/jump-to/first-unread-message The 'by client' endpoint sometimes returns duplicate client records. I've tried it with/without a band filter, behaviour is similar. Btw I do not see any duplicates on the 'by device' endpoint. Without a band filter, there are sometime two or more identical records for the same client. With band filters and consolidating data for the three bands, the duplication may occur on one, two or all three bands. This org has > 40,000 clients in the sample period (September 2023), running for each band, over 6,000 network-client records have a least one duplicate in one or more bands, one has 20 in all three bands. Number of copies per network-client-band, should only be 1 copy per unique network-client-band... unique network-client-band copies 114792 1 4299 2 920 3 188 4 247 5 85 6 28 7 19 8 19 9 20 10 19 11 43 12 56 13 11 14 12 15 18 16 28 17 19 18 14 19 3 20 Sample with network and MAC hidden (any given client is on just one network, id-MAC are identical)... period id band upTotal upLost upLost% downTotal downLost downLost% 2023-09 k04037a 2.4 0 0 0 0 0 0 2023-09 k04037a 2.4 0 0 0 0 0 0 2023-09 k04037a 5 0 0 0 0 0 0 2023-09 k04037a 6 0 0 0 0 0 0 2023-09 k04037a 6 0 0 0 0 0 0 2023-09 k040e89 2.4 3036 80 2.6 2855 245 8.6 2023-09 k040e89 2.4 3036 80 2.6 2855 245 8.6 2023-09 k040e89 5 309095 2473 0.8 595930 7173 1.2 2023-09 k040e89 6 0 0 0 0 0 0 2023-09 k040e89 6 0 0 0 0 0 0 2023-09 k046f49 2.4 22 0 0 12 0 0 2023-09 k046f49 5 0 0 0 0 0 0 2023-09 k046f49 6 0 0 0 0 0 0 2023-09 k046f49 6 0 0 0 0 0 0 2023-09 k0488f2 2.4 994 31 3.1 860 59 6.9 2023-09 k0488f2 2.4 994 31 3.1 860 59 6.9 2023-09 k0488f2 5 20936 42 0.2 28124 2166 7.7 2023-09 k0488f2 6 0 0 0 0 0 0 2023-09 k0488f2 6 0 0 0 0 0 0 2023-09 k077886 2.4 0 0 0 0 0 0 2023-09 k077886 5 3651 61 1.7 11041 1661 15 2023-09 k077886 6 0 0 0 0 0 0 2023-09 k077886 6 0 0 0 0 0 0 2023-09 k0c5216 2.4 51 0 0 33 0 0 2023-09 k0c5216 5 0 0 0 0 0 0 2023-09 k0c5216 6 0 0 0 0 0 0

sungod · ‎Oct 7 2023

I have scripts that run every few minutes on some organizations, there's no sign of similar behaviour. Are these outages you see on a particular shard? If it is then I'd open a support case.

sungod · ‎Oct 2 2023

Current version is 1.37.3 https://pypi.org/project/meraki/1.37.3/ I don't believe this call existed in 1.7.2!

sungod · ‎Sep 30 2023

Is your Meraki Python library up to date?

sungod · ‎Sep 27 2023

Today the occupancy is back up according to location analytics, and again I'm seeing data gaps on some of the MT40s. All firmware was/is up to date, there are plenty of available gateway devices within close range of the MT40s. No sign of any gaps on MT14 and MT10 sensors in the same area. Time to open a case.

About sungod

sungod

Community Record

Badges