(RADIATOR) Cisco 7920 Wireless IP Phone & Radiator (LEAP authorization)

[Mike McCauley]

Hello Jan,


On Thursday 02 September 2004 17:44, Jan Tomasek wrote:
> PS: Due troubles with size limit is at this list are attachements located
> at: http://www.tomasek.cz/stuff/radiator/20040902/radiator-leap.log.bz2
> http://www.tomasek.cz/stuff/radiator/20040902/radiator-file.bz2
>
> Jan
>
> -------- Original Message --------
> Subject: Cisco 7920 Wireless IP Phone & Radiator (LEAP authorization)
> Date: Mon, 30 Aug 2004 14:16:57 +0200
> From: Jan Tomasek <jan at tomasek.cz>
> To: radiator at open.com.au
>
> Hi,
> we have two examples of those 'wireless' phones, they are funny devices
> which can't hold more than 1/2 of day with their batery. ;) But that
> doesn't belongs here. What does, is that those phones are not able to
> authorize.
>
> Manual says it should be using LEAP (which was confirmed as working by an
> Windows client from Intel). For some reason Radiator things it is using
> PEAP.

Thats because PEAP is the first EAP type mentioned in your EAPType line. It 
wil be offered as the default EAP type.

>
> Log file and Radiator configuration is attached. Has anyone idea what is
> bad? Or has anyone successfuly tested them?

There was no log file attached. Sorry. You can send it to me privately if it 
is too big for the list size limits.

>
>
> BTW: How does Radiator recognize what EAP type should be used?

It initially offers the first EAP type mentioned in the EAPType parameter. If 
the client likes that protocol it starts the EAP handshake, else it sends an 
EAP NAK containing the preferred EAP type.

So, it should work OK even if PEAP is your preferred type, provided the client 
correctly initiates LEAP. I would need to see the entire log to check whether 
this is happening OK.

>
> Mon Aug 30 13:12:40 2004: DEBUG: Handling with EAP: code 2, 3, 6

Thats just the EAP code, EAP identifier and message length.

> Mon Aug 30 13:12:40 2004: DEBUG: Response type 3
> Mon Aug 30 13:12:40 2004: INFO: EAP Nak desires type 17
>
> I assumed that it is somehow identified by "EAP: code 2, 3, 6" but LEAP has
> 17 ? I'm able to identify '17' in first packet:
>         EAP-Message = <2><3><0><6><3><17>

This is an EAP NAK, saying the client want EAP type 17.

> but not in secoond
>         EAP-Message =
> <2><4><0>/<17><1><0><24>n<12><223><164>P<191>D<228><167><156>A<244><180><0>
>`<27><205>KZ<148><215><205><142>Gjanru at cesnet.cz 
This is an EAP-LEAP version 1 response containing the peer response and the 
user name. Looks like the EAP-LEAP handshake was happening OK.

>there is to many other 
> numbers ;) (Taken from attached file radius-leap.log). Isn't somewhere an
> simplified doc about this? I'm getting interested in this but still not
> enought to read all that corresoponding RFC.

Its never that simple :-)

Cheers.

>
> Best regards

-- 
Mike McCauley                               mikem at open.com.au
Open System Consultants Pty. Ltd            Unix, Perl, Motif, C++, WWW
9 Bulbul Place Currumbin Waters QLD 4223 Australia   http://www.open.com.au
Phone +61 7 5598-7474                       Fax   +61 7 5598-7070

Radiator: the most portable, flexible and configurable RADIUS server 
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, 
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, 
TTLS, PEAP etc on Unix, Windows, MacOS etc.

--
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.