Ready for 2.2.7?
aland at deployingradius.com
Tue Mar 31 19:13:27 CEST 2015
On Mar 31, 2015, at 1:00 PM, Jouni Malinen <jkmalinen at gmail.com> wrote:
> I was going to say that I cannot reproduce it anymore, but then I
> remembered that I tested with number of FreeRADIUS versions today.
> This does not show up with 2.2.6, but does show up with 3.0.2. I
> didn't have a more recent 3.0.x compiled in the earlier tests, but now
> that I checked with 3.0.7, it looks like the issue has been fixed.
That's good. We've added a lot of regression tests in the last 6 months. It helps enormously.
> The error with 3.0.2 when eap_workaround=0 is used looked like this:
> EAP-PEAP: TLS done, proceed to Phase 2
> EAP-PEAP: Selected Phase 2 EAP vendor 0 method 26
> EAP-MSCHAPV2: Invalid header: len=71 ms_len=33
Ah... the extended EAP packets. That came up on the list:
The supplicant was sending an entire EAP packet inside of an extended EAP packet. i.e. the extended EAP packet didn't contain the data for EAP type 26. Instead, it contain a complete EAP packet.
Is that really what's supposed to happen? I don't see that in the RFCs.
> Anyway, with that having already been addressed, eap_workaround=0
> seems to work fine with both 2.2.6 and 3.0.7 and that does allow TLS
> session ticket to be used.
>> And the inner EAP data in PEAP is... stupid. Very, very, stupid. <sigh>
> Indeed.. And to make it even worse, the behavior is different between
> PEAP v0 and v1 (or v2 that almost no one supports)..
More information about the Freeradius-Users