[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freeradius-users
Subject:    Re: Is there some kind of trick to make Cisco LEAP work???
From:       "Alan DeKok" <aland () ox ! org>
Date:       2004-08-31 20:58:11
Message-ID: 20040831210027.9769C16CD2 () mail ! nitros9 ! org
[Download RAW message or body]

Coates Carter <coates.carter@richmond.edu> wrote:
> The ACS server and freeradius return nearly identical attributes.  The  
> first difference is that in the first Access-Challenge, ACS returns  
> Session-Timeout integer of value 10.  Freeradius does not return this  
> attribute by default.  I'll have it return that attribute in the next  
> test.  I doubt that is the problem, but you never know.

  I'm not sure what else it would be.

> More significant is the value of State in each Access-Challenge.
> The ACS server sends a State with 48 octets of data, like this...
> 
> 3C CE 0B C2 1F C4 EC 00 00 00 00 00 00 00 00
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 4A 8B 02 C7 5F 73 30 72 79 4C BE 81 58 77 08 FC
> 
> Freeradius sends a State with 16 octets of data, like this...
> 
> 08 69 18 A9 AF 56 71 B1 2C E9 A9 2A 35 CA D9 94

  That shouldn't matter.  The State attribute is defined to be opaque
nonsense, so far as the NAS is concerned.

> The RFC on this attribute (  
> http://www.freeradius.org/rfc/rfc2865.html#State ) says the value is  
> application specific, and I'm not sure which module produces it, how to  
> decode it, etc.  But it seems clear to me that this is the fly that  
> choked the horse (Cisco's WLSE leap/eap/radius client being the horse).

  The state is meaningless, other than a series of bytes which the
server interprets.  It's implementation-specific, and the NAS thinks
it means anything.

  Alan DeKok.


- 
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
[prev in list] [next in list] [prev in thread] [next in thread]