I am facing a persistent issue with the mAP 2nd (RBmAP2nD) after upgrading to v7.20. I have a fleet of these devices that need to connect as stations to a Cisco-based enterprise network (WPA2-EAP/PEAP).
The Problem: Since the upgrade from v6.48 to v7.20, the devices can no longer authenticate. The log shows a continuous "802.1x authentication timeout". The same configuration worked perfectly on v6.
Supplicant Identity: Explicitly set supplicant-identity and mschapv2-username to the same value.
Bridge Mode: Set bridge-mode=disabled via CLI.
Management Protection: Set management-protection=disabled.
MTU: Lowered wlan1 MTU to 1200 to avoid TLS fragmentation issues.
It seems like the new v7 supplicant is not handling the Identity-Request/Challenge flow from the Cisco Controller correctly. Has anyone successfully connected a 16MB Flash device (mAP 2nd) to a Cisco Enterprise environment under v7.20?
Are there any hidden system/settings or specific eap-methods flags in v7.20 that I'm missing?
Not an answer to your question, but is there a reason why you cannot downgrade them to 6.49.19 and call it a day?
After all it is a station, more or less "locked" to a given SSID, it is unlikely that any vulnerability exists that can be used on those devices.
Then you can make experiments with just one of those devices.
BTW one of the (good) changes in 6.49.19 should be that the upgrade to any v7 version should be more reliable.
Current "long-term" (but it won't change anything I believe) is however 7.20.8.
I would try first an earlier v7 version like 7.12 or 7.13.x, just to see if the issue is v6 vs. v7 or it it is related to more recent versions of v7 only, then try 7.15.3 that seems like have better compatibility: https://forum.mikrotik.com/t/eap-peap-mschapv2-as-station-with-v7/
and work from that on more recent versions, it is entirely possible that it was "fixed" and then reoccurred as a regression bug.
Some devices are already shipped with RouterOS v7 (or newer) from the factory. On these models, it is not possible to downgrade to RouterOS v6 due to the factory-installed OS.
Therefore, I have to configure everything for the newer firmware version in case we lose some devices due to defects.
"Some" come with v7, but you can easily netinstall v6 [on RBmAP2nD], depending on what is written in /system resources factory software,
completely ignoring the installed factory-firmware.
And even if they came with v7, why update the ones that work? It doesn't make sense...
this might not help you, but I have a exactly this device successfully connecting to a mikrotik wifi ax (new wifi driver on the access point) using EAP-TLS (using a radius server on the backend, so for the access point itself it should be the same as any other eap method). I did not change the mtu of the wlan1 interface tough.
else the setup is probably the same as yours: aes-ccm for both unicast and group cipher, management-protection=allow (its wpa2, probably the same as disable).
what I also set was tls-mode=dont-verify-certificate, mainly because of laziness and not wanting to have a situation where the device cannot connect because the clock is totally off.
Does 7.20 already have multiple certificate root categories? Is the CA (if tls certificates are checked) on the device?
Also do you see some activities on the radius server?
Thanks for the suggestions, but there is a major practical and professional hurdle here: Consistency and Reliability.
We are using these mAP devices in a hospital environment. They are connected to our mobile C-arm X-ray systems, which only have RJ45 ports. Up until now, the mAP was the perfect, cost-efficient solution for providing these medical devices with wireless connectivity to our Cisco infrastructure.
However, the "Lottery System" we are currently facing with RouterOS versions is not acceptable. We receive mixed batches: some with v6, some even newer (7.x), and we have already encountered units where a Netinstall downgrade to v6 is physically blocked by the hardware's "Minimum Software" lock or in better terms: *"Each device is produced with a specific 'factory' version. This version is the lowest possible version the device can run."*
In an other post normis said:
Downgrade can break compatibility, worsen performance or make device unusable. Parts are changed often, new RouterOS/RouterBOOT is needed to support new revision of hardware.
If a C-arm's wireless adapter fails during a shift, the replacement must work out-of-the-box with the current factory firmware (v7.20+).
If we cannot find a reliable, future-proof configuration for RouterOS v7 that satisfies our Cisco ap requirements, we will be forced to move away from MikroTik entirely and look for a different hardware vendor for our medical mobile units.
Has anyone successfully analyzed why the v7.20 fails where v6 succeeded? Is there a specific TLS fragment or MSCHAPv2 phase change in v7 that causes the Cisco timeout?
Thanks for the feedback! It's good to know that EAP-TLS is working for you, but I believe the PEAP/MSCHAPv2 flow with a Cisco is where the regression lies.
RADIUS Activity: Our Cisco specialist sees the "Identity" phase, but the process never reaches the next challenge. The logs show a "Client Timeout" because the mAP doesn't seem to respond to the next EAP-Request.
To provide more detail on the failure pattern:
The mAP actually shows as "connected" in the registration table for one minute. However, during this time, it is not requesting or receiving an IP address. After about 60 seconds, the connection drops and the "802.1x authentication timeout" error appears in the log.
Certificates: Since we use PEAP, we have no client certificate. I've set tls-mode=dont-verify-certificate
the tls-mode was actually just a idea because in theory the mikrotik could verify the radius server certificate, but reading the documentation that is not the case (as far as I understand it probably ignores the certificate of the radius server)
I’ve migrated to eap-tls some time ago, so I cannot easily check if there is a regression here, but it definitely worked on some older v7 firmwares (always talking connecting to mikrotik gear, but I doubt that cisco is the issue here).
My radius server always also accepted eap-ttls with mschapv2, last time I used that.
If I understand it correctly the identiy phase is the packet that contains supplicant-identiy and eap “nested” first packet. Would be interresting if the actual tls connection (actually peap is a tls tunnel where inside a eap-mschap2) is done and eap-mschap2 is broken or the tls part of peap is broken. If the latter is the case maybe eap-ttls works
Well, then you should raise a ticket with support, but if you have the time to check 7.15.3 (IF it works) it would at least give them a starting point to find in which version the issue has resurfaced.
