About KarstenI

KarstenI

Also, thanks for testing the script. I'm glad that it's already highlighted some devices 🙂 I was very pleased that the script also directly took the API-Key from the environment instead from the parameter. Perhaps the CSV would be better with one client per line. It would directly give an info about the amount of affected devices.

KarstenI

Hi all, for one customer we are using the Sentry Cloud authentication for Wireless. When the certificate renewal was announced, I looked a couple of times that all users were online in the dashboard and thought "everything is fine". Now I checked with the script that @PaulF provided to find out that 71 out of 73 PCs don't have the new certificate. I also checked the certificates list in the dashboard and yes, the only radius.meraki.com certificate is one that expired on August 01, 2022. The documentation says that the devices just have to be online and I also saw up to date "check-in" in the SM dashboard. Any idea? Karsten

KarstenI

But a correct one ... 😉 Edit: Argh, what I mean is that the complaint is correct! This feature needs some improvement.

KarstenI

That's the server with the probably worst logging available. Perhaps someone with knowledge of that system can jump in ...

KarstenI

Yes, but the question is if the RADIUS server processed the last request and just the reply got lost somewhere of if the RADIUS server was not able to process the last request. Which RADIUS server is it?

KarstenI

Does the RADIUS server log in both cases a Success? Or what is the Log for the failed sessions?

KarstenI

When you look into the two final RADIUS Access-Requests (the working and the failed), do you spot any differences?

KarstenI

If the serial number doesn't work, I would assume that you've already set a new password in the dashboard and now need to use admin and this password. Just because the MX is in a new location it doesn't mean that the recent config is not used any more.

KarstenI

@Gsintes I have to disappoint you, also this year the socks are mine ... (No, better luck this year, everyone running a Meraki network deserves Meraki Swag!)

KarstenI

Option three, ChatGPT ... 😉 Ok, actually I am old fashioned with this and I still use a search engine, but mostly start with DuckDuckGo.

KarstenI

I think the problem you are running into is based on that Meraki doesn't yet support transition mode with OWE. There you would see one SSID and the capable client would use OWE and the older client would use the standard open mode. Unless that is implemented by Meraki I would either not use OWE or use two SSIDs with different names like "Guest" and "Guest-Secure". But I am not sure what you mean with the EAP methods, This is typically related to an Enterprise WPA implementation and will always show up on the client devices.

KarstenI

Another option is to configure a DHCP server on the uplink VLAN. If the MX can't work with the configured IP it falls back to DHCP. IF it is a trunk, do this on the native VLAN.

KarstenI

My New Year resolution for this year is to catch up with the previous years resolutions ... 🙂 And with having the term " 500-220 " multiple times in this thread, I could think of a New Years resolution for @AmyReyes and the Community team: What about the CMSS-badges?

KarstenI

@RaphaelL Last year I missed you, but perhaps we meet this year. (I just declare that I identify as one of the nice people 😀 ) And good luck with the rest!

KarstenI

As already mentioned, no problem with this setup. If your MX is the only device to use this IP subnet, you can ask the ISP to route it to your MX IP. It's slightly more secure and you get one more usable IP.

KarstenI

Lucky you ... 😉

KarstenI

The way the actual WPA3-SAE implementation is done, MPSK (or iPSK without RADIUS) can not work. The AP had to try multiple PSKs until the right one is matched. But this was prohibited by design in WPA3. On each connect, only one PSK can be checked. iPSK with RADIUS could work, but probably needs to be implemented.

KarstenI

MultiGig is always backward compatible to 1Gig (or at least I have not seen a vendor having it not compatible)

KarstenI

Not sure if I find it any more. It was also some times on the "Known Issues" list of the release notes.

KarstenI

The problem was discussed before. It seems they are not able to really reproduce the problem. I think the uptime of the switch is part of the problem. That a long uptime with no extra reload is more problematic than a longer uptime with a reload.

KarstenI

This sounds exactly like the known bug that L3 switches stop L3 forwarding after changes in the L3 config. L2 forwarding typically is not affected. I was running into this bug many times. What helps: If the problem is already there, reload of the switch. When the switch gets reloaded before the change I didn't see this problem. I have the impression that it happens more often it the switch was not reloaded another time after an update. I now always do an additional reload and it happens not that often any more.

KarstenI

The most pressing problem on the MX is IMO still the missing inbound filter for L2L-VPN traffic.

KarstenI

If there are no clients connected, the fastest way to get to a working stack is likely to factory reset the switches and build the stack again following exactly the instructions (like when to switch on the switches). https://documentation.meraki.com/MS/Stacking/Switch_Stacks#Configuring_a_Physical_Switch_Stack

KarstenI

Dreaming is allowed ... 😉 But this dream will likely never come true. (Just my guess).

KarstenI

I just got an answer from Support: RADIUS-Authorisation is not supported at all on the MX, only Authentication. Ignoring the VLAN-attribute that is sent by the RADIUS server is the expected behaviour. I just added feedback on this topic on the dashboard.

KarstenI

Karsten Iwen

Community Record

Badges