Hi Alan,
On Mar 3, 2015, at 10:33 AM, Phil Mayers <p.mayers@imperial.ac.uk> wrote:
Well, it expects a response or a plain NAK there because that's what MS- PEAP says are the only valid replies, once you pick apart the state machine.
It's probably a good idea to be looser and accept the expanded NAK too, on the FR side; no real harm to it.
It’s not an expanded NAK. It’s a gigantic piece of garbage. The supplicant should be thrown in the garbage. It goes like this:
FreeRADIUS does PEAP. Once the inner tunnel is set up, FR sends an EAP- MSCHAPv2 challenge packet.
The supplicant responds with an extended type:
0x021d 0046 fe extended type 000000 IETF Private enterprise code 0000001a EAP-MSCHAPv2 021d 003a 31 ???? Another EAP packet with EAP-Type 49, EAP-IKEv2 ???
And then this:
6e882ba02b15bc9aec09decfe03db1fb0000000000000000ad6990749d5255b204c8a2d90f e0e1496dc5ee88dc54bfc30074657374
The supplicant is a piece of garbage. There is NO REASON to send an extended type packet. On top of that, the contents of the extended type are the actual EAP type data. NOT another EAP packet with EAP header, length, etc.
Thanks! That input is greatly appreciated! I hope Cisco will agree with this PoV though. ;-)
All of this nonsense could have been avoided if the OP posted the debug log as suggested in the FAQ, README, “man” pages, web pages, and daily on this list. But no…making it hard for people to help you is a *great* idea.
Well, I'm trying and learning. And retrofitting new services onto existing configs is never easy. That's why I tried first to attach the logs as individual files to make reading/comparing them easier and not as tedious as having them inline. For some reason the mailing list didn't let them through though. Any hints on why the use_tunneled_reply is needed to get the CUI passed to the Access-Accept? For some reason the default config talks about CUI but doesn't seem to implement it to work without use_tunneled_reply - at least that's what my tests say so far. Do you reckon? Best, Kilian