EAP-Message incorrectly decoded as LEAP?
Hi, I've just set up a new 2.1.12 that supports only EAP-TLS & EAP-TTLS. I ran a blind-test with radtest (EAP-MD5 requested), and got: Sending Access-Request packet to host 127.0.0.1 port 1812, id=88, length=0 User-Name = "foo@ltett.lu" User-Password = "bar" NAS-IP-Address = 158.64.1.155 NAS-Port = 123 Message-Authenticator = 0x00 EAP-Code = Response EAP-Type-Identity = "foo@ltett.lu" EAP-Message = 0x0257001101666f6f406c746574742e6c75 Received Access-Challenge packet from host 127.0.0.1 port 1812, id=88, length=64 EAP-Message = 0x015800061520 Message-Authenticator = 0x735a717844469d67a2215716e090d9e2 State = 0x02e3245002bb31c7ca78f83bc6164863 EAP-Id = 88 EAP-Code = Request EAP-Type-LEAP = 0x20 The last line speaking about LEAP, which was a surprise. Decoding the EAP-Message from the server, the request payload is EAP-Type 0x15 - EAP-TTLS, just as expected. So no real problem, just a source of confusion... why does radtest decode things as EAP-Type-LEAP here? Maybe something wrong in the dictionary.freeradius.internal: # these are PW_EAP_X + 1280 ATTRIBUTE EAP-Type-Identity 1281 string ATTRIBUTE EAP-Type-Notification 1282 string ATTRIBUTE EAP-Type-NAK 1283 string ATTRIBUTE EAP-Type-MD5 1284 octets ATTRIBUTE EAP-Type-OTP 1285 string ATTRIBUTE EAP-Type-GTC 1286 string ATTRIBUTE EAP-Type-TLS 1297 octets ATTRIBUTE EAP-Type-SIM 1298 octets ATTRIBUTE EAP-Type-LEAP 1301 octets ATTRIBUTE EAP-Type-SIM2 1302 octets ATTRIBUTE EAP-Type-TTLS 1305 octets ATTRIBUTE EAP-Type-PEAP 1309 octets This gives LEAP 21 = 0x15 (which is actually TTLS!), and TTLS 25 =0x19 (which is actually PEAP!), and PEAP 29 = 0x1D (which is actually EAP-MSCHAPv2!) Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473
Stefan Winter wrote:
Maybe something wrong in the dictionary.freeradius.internal:
Yes.
This gives LEAP 21 = 0x15 (which is actually TTLS!), and TTLS 25 =0x19 (which is actually PEAP!), and PEAP 29 = 0x1D (which is actually EAP-MSCHAPv2!)
Solution: $ egrep VALUE dictionary.freeradius.internal | grep EAP-Type | awk '{print "ATTRIBUTE EAP-Type-" $3 " " 1280+$4 " octets"}' > foo;./format.pl foo And copy the resulting file into dictionary.freeradius.internal, to replace the existing (wrong) EAP-Type-* definitions. Alan DeKok.
Hi, yep, that did the trick. Could these changes make it to 2.1.13 / 2.2.0? Stefan On 13.02.2012 11:20, Alan DeKok wrote:
Stefan Winter wrote:
Maybe something wrong in the dictionary.freeradius.internal:
Yes.
This gives LEAP 21 = 0x15 (which is actually TTLS!), and TTLS 25 =0x19 (which is actually PEAP!), and PEAP 29 = 0x1D (which is actually EAP-MSCHAPv2!)
Solution:
$ egrep VALUE dictionary.freeradius.internal | grep EAP-Type | awk '{print "ATTRIBUTE EAP-Type-" $3 " " 1280+$4 " octets"}'> foo;./format.pl foo
And copy the resulting file into dictionary.freeradius.internal, to replace the existing (wrong) EAP-Type-* definitions.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
-- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473
participants (2)
-
Alan DeKok -
Stefan Winter