Ready for 2.2.7?

[Alan DeKok]

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:

http://lists.freeradius.org/pipermail/freeradius-users/2015-March/075995.html

  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.

  OK.

>>  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)..

  Yeah...

  Alan DeKok.