On Jul 13, 2021, at 9:57 AM, Joe Garcia <joe27256@gmail.com> wrote:
The client? A no-name embedded one used with SCADA devices that have to be controlled from central servers. If it was up to me they'd just be FreeRADIUS, but unfortunately some have to be NPS since there's lots of different vendors involved.
Arg.
Already done that, we've taken Wireshark captures, the eapol_test and FreeRADIUS logs, and diagnostics from the client, and made things identical to what eapol_test sends (as far as we can tell, there may be stuff inside the PEAP tunnel that we can't see and aren't not aware of).
Can you send them to me offline? Ideally also with some test certs / private keys, so that I can decode the packet traces and see what's up.
We've really tried everything we can think of, so it may be a case of someone seeing this and remembering some obscure magic they used to get it to work.
I don't recall seeing any of this before.
What wpa_supplicant does is ignore the message and re-send the Identity Response it's just sent, which continues the negotiation.
Ah. That's reasonable, I guess. But sending a crappy EAP type is still stupid.
This is one of the bits that reverse-engineering the flow from eapol_test/wpa_supplicant helped with. So for anyone else who's faced with this, when doing PEAP/MSCHAPv2 with NPS, when you're expecting to get the MSCHAPv2 Challenge if instead you get an EAP vendor-specific undocumented Microsoft blob back, re-send the Identity Response a second time and then you'll get the MSCHAPv2 Challenge you should have got the first time.
That just depresses me. Alan DeKok.