Freeradius reply attribute problem when using PEAP

[Dale Blount]

On Tue, 2014-08-12 at 18:36 +0200, Alan DeKok wrote:

> > Does PEAP require a different inner-tunnel than TTLS does?  At the
> > moment they are both using the same default inner-tunnel.
> 
>   They're using the same inner tunnel.
> 
>   There's no magic here.  Everything is in the debug log.  If the
> replies are different, it's because the server does *different* things
> in the inner-tunnel.  And if you read it, it does.
> 
>   Stop trying to debug the entire EAP thing.  It's a waste of your time.
>  Debug the inner-tunnel, as I said.  See the comments at the top of the
> inner-tunnel file (in recent versions)

I've already debugged the inner-tunnel using the radtest commands in the
top of the inner-tunnel file.  They both work and pass the Ruckus-Role
just fine:

$ radtest rickjames XXXX 127.0.0.1:18120 0 ZZZZ 
SOFT ASSERT FAILED src/lib/valuepair.c[235]: vp
Sending Access-Request Id 141 from 0.0.0.0:33424 to 127.0.0.1:18120
	User-Name = 'rickjames'
	User-Password = 'test1234'
	NAS-IP-Address = 192.168.211.189
	NAS-Port = 0
	Message-Authenticator = 0x00
	Framed-Protocol = PPP
Received Access-Accept Id 141 from 127.0.0.1:18120 to 127.0.0.1:33424
length 42
	Ruckus-Role = 'TestSite-Premium'
$ radtest -t mschap rickjames XXXX 127.0.0.1:18120 0 ZZZZ
SOFT ASSERT FAILED src/lib/valuepair.c[235]: vp
Sending Access-Request Id 2 from 0.0.0.0:58096 to 127.0.0.1:18120
	User-Name = 'rickjames'
	NAS-IP-Address = 192.168.211.189
	NAS-Port = 0
	Message-Authenticator = 0x00
	Framed-Protocol = PPP
	MS-CHAP-Challenge = 0x1a0e8931efa7d3bf
	MS-CHAP-Response =
0x00010000000000000000000000000000000000000000000000000cbf65ea5964d246e0d583e86aadcb125ab474f95c97d27d
Received Access-Accept Id 2 from 127.0.0.1:18120 to 127.0.0.1:58096
length 106
	Ruckus-Role = 'TestSite-Premium'
	MS-CHAP-MPPE-Keys = 0x624aac413795cdc1ae33a32dca8c9821844f740d5b3f4d6c
	MS-MPPE-Encryption-Policy = Encryption-Allowed
	MS-MPPE-Encryption-Types = RC4-40or128-bit-Allowed



I did find something odd, though.  I upgraded to 3.0.4rc1 based on a few
bug reports I had found earlier to see if it would provide additional
debug.  Now EAP-PEAP connects the first time radiusd is started, and
fails subsequent times.  If I switch the client
(NetworkManager/wpa_supplicant) from PEAP to TTLS it connects, and if I
switch it back to PEAP it'll connect again as long as I keep switching
the type.  I then disabled cache in mods-enabled/eap and it'll work
repeatedly using PEAP on every client device I can find.

Logs:
http://dale.us/temp/fr-304rc1-1.log
and broken out into the separate attempts:
http://dale.us/temp/fr-304rc1-1-works.log
http://dale.us/temp/fr-304rc1-1-broken.log



Any hints?

Dale