TTLS and PAP
Folks,
I'm repeating this message incase people thought it was not the
original. I had the Fw: on the front of the subject.
I'm trying to get TTLS/PAP working using freeradius 1.0.4. I must have
it configured incorrectly because its giving a Segmentation fault just
before giving the Access-Accept EAP-Success back to the switch. I
have searched the archives for a solution but not found help to sort my
problem out.
I have played around with the configuration but don't fully understand
what I'm doing. Could someone point me to a place where I can read and
understand how the authenticate and autorize sections work. The
explanation in the radiusd.conf file don't seem to click with me.
I don't understand is why the modcall[authorise] appear often in request
processing before modcall[authenticate]. I thought the order was to
authenticate a user and then once we are sure they are who they say they
are then we authorise them to use the network.
Thanks for any help,
Martin.
radiusd.conf
authenticate {
Auth-Type PAP {
pap
}
eap
}
authorize {
preprocess
eap
files
}
Users file..
Client certificate Auth-Type := Local, User-Password == bradley
Service-Type = Framed-User,
Framed-Compression = Van-Jacobsen-TCP-IP
Processing the authorize section of radiusd.conf
modcall: entering group authorize for request 3
modcall[authorize]: module preprocess returns ok for request 3
users: Matched entry DEFAULT at line 162
modcall[authorize]: module files returns ok for request 3
rlm_eap: EAP packet type response id 34 length 200
rlm_eap: No EAP Start, assuming it's an on-going EAP conversation
modcall[authorize]: module eap returns updated for request 3
modcall: group authorize returns updated for request 3
rad_check_password: Found Auth-Type System
rad_check_password: Found Auth-Type EAP
Warning: Found 2 auth-types on request for user 'anonymous'
auth: type EAP
Processing the authenticate section of radiusd.conf
modcall: entering group authenticate for request 3
rlm_eap: Request found, released from the list
rlm_eap: EAP/ttls
rlm_eap: processing type ttls
rlm_eap_ttls: Authenticate
rlm_eap_tls: processing TLS
rlm_eap_tls: Length Included
eaptls_verify returned 11
TLS_accept: SSLv3 read client key exchange A
TLS_accept: SSLv3 read finished A
TLS_accept: SSLv3 write change cipher spec A
TLS_accept: SSLv3 write finished A
TLS_accept: SSLv3 flush data
(other): SSL negotiation finished successfully
SSL Connection Established
eaptls_process returned 13
modcall[authenticate]: module eap returns handled for request 3
modcall: group authenticate returns handled for request 3
Sending Access-Challenge of id 34 to 10.230.199.248:1126
EAP-Message =
0x0123003d1580003314030100010116030100288b7a33f454f760f4cddff2f95941
b215a6f3d73b5e422d1744b2201bee31448f10dc78f33f354476
Message-Authenticator = 0x
State = 0x49b28c5e2307f384db00487f11336474
Going to the next request
Waking up in 5 seconds...
rad_recv: Access-Request packet from host 10.230.199.248:1126, id=35,
length=248
User-Name = anonymous
NAS-IP-Address = 10.230.199.248
NAS-Port = 2
State = 0x49b28c5e2307f384db00487f11336474
Calling-Station-Id = 00:06:5b:d6:ff:24
NAS-Identifier = radius-netgear
NAS-Port-Type = Ethernet
EAP-Message =
0x02230078150017030100189e2c7d7fea093fe36d2ad301f92cc2ef4cba50563b00a0a8
1703010050b5955c43a5cd51375cebde00ed386a2f4273385aa3f6b0b2c6f7e15b73a75e
e8f64e15abdca0a875fd3408d3ce811a76580cee45fc540215f84bcc2f99a95cc5199a36
da952c0a76243f7f7645f4327b
Message-Authenticator = 0x3ddd5d8d65f10f4a26c7db7ab52a96db
X-Ascend-Token-Idle = 1
Processing the authorize section of radiusd.conf
modcall: entering group authorize for request 4
modcall[authorize]: module preprocess returns ok for request 4
users: Matched entry DEFAULT at line 162
modcall[authorize]: module files returns ok for request 4
rlm_eap: EAP packet type response id 35 length 120
rlm_eap: No EAP Start, assuming it's an on-going EAP conversation
modcall[authorize]: module eap returns updated for request 4
modcall: group authorize returns updated for request 4
rad_check_password: Found Auth-Type System
rad_check_password: Found Auth-Type EAP
Warning: Found 2 auth-types on request for user 'anonymous'
auth: type EAP
Processing the authenticate section of radiusd.conf
modcall: entering group authenticate for request 4
rlm_eap: Request found, released from the list
rlm_eap: EAP/ttls
rlm_eap: processing type ttls
rlm_eap_ttls: Authenticate
rlm_eap_tls: processing TLS
eaptls_verify returned 7
rlm_eap_tls: Done initial handshake
eaptls_process returned 7
rlm_eap_ttls: Session established. Proceeding to decode tunneled
RE: FW: TTLS and PAP
Alan,
Sorry about duplicating my original email. I found your reply about 3
seconds after doing that.
Here is the stack trace.
Maybe my version of ssl is too old?
[EMAIL PROTECTED] bin]$ openssl
OpenSSL version
OpenSSL 0.9.7b 10 Apr 2003
#0 0x402d4a97 in eaptls_gen_mppe_keys (reply_vps=0x8179c08,
s=0x8157790, prf_label=0x402da5d9 ttls keying material) at
mppe_keys.c:136
136 memcpy(p, s-s3-client_random, SSL3_RANDOM_SIZE);
(gdb) bt
#0 0x402d4a97 in eaptls_gen_mppe_keys (reply_vps=0x8179c08,
s=0x8157790, prf_label=0x402da5d9 ttls keying material) at
mppe_keys.c:136
#1 0x402d8912 in eapttls_authenticate (arg=0x814dcb0,
handler=0x81576e8) at rlm_eap_ttls.c:253
#2 0x4002a627 in eaptype_call (atype=0x814dba0, handler=0x81576e8) at
eap.c:167
#3 0x4002a9f5 in eaptype_select (inst=0x810fe60, handler=0x81576e8) at
eap.c:353
#4 0x40029d89 in eap_authenticate (instance=0x810fe60,
request=0x8179b38) at rlm_eap.c:271
#5 0x08054c7a in call_modsingle (component=0, sp=0x810ebe8,
request=0x8179b38, default_result=0) at modcall.c:219
#6 0x08054e6e in modcall (component=0, c=0x810ebe8, request=0x8179b38)
at modcall.c:344
#7 0x08054d37 in call_modgroup (component=0, g=0x814f3e0,
request=0x8179b38, default_result=0) at modcall.c:252
#8 0x08054e1d in modcall (component=0, c=0x814f3e0, request=0x8179b38)
at modcall.c:335
#9 0x0805492b in module_authenticate (auth_type=6, request=0x8179b38)
at modules.c:891
#10 0x0805198b in rad_check_password (request=0x8179b38) at auth.c:353
#11 0x08051d53 in rad_authenticate (request=0x8179b38) at auth.c:644
#12 0x0804d5a9 in rad_respond (request=0x8179b38, fun=0x8051a9c
rad_authenticate) at radiusd.c:1642
#13 0x0804d2ea in main (argc=2, argv=0xb514) at radiusd.c:1427
#14 0x42017499 in __libc_start_main () from /lib/i686/libc.so.6
123 void eaptls_gen_mppe_keys(VALUE_PAIR **reply_vps, SSL *s,
124 const char *prf_label)
125 {
126 unsigned char out[2*EAPTLS_MPPE_KEY_LEN],
buf[2*EAPTLS_MPPE_KEY_LEN];
127 unsigned char seed[64 + 2*SSL3_RANDOM_SIZE];
(gdb) l
128 unsigned char *p = seed;
129 size_t prf_size;
130
131 prf_size = strlen(prf_label);
132
133 memcpy(p, prf_label, prf_size);
134 p += prf_size;
135
136 memcpy(p, s-s3-client_random, SSL3_RANDOM_SIZE);
137 p += SSL3_RANDOM_SIZE;
(gdb) print s
$2 = (SSL *) 0x8157790
(gdb) print s-s3
$3 = (struct ssl3_state_st *) 0x0
Regards,
Martin.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Alan
DeKok
Sent: 19 July 2005 20:01
To: FreeRadius users mailing list
Subject: Re: FW: TTLS and PAP
[EMAIL PROTECTED] wrote:
I'm trying to get TTLS/PAP working using freeradius 1.0.4. I must
have
it configured incorrectly because its giving a Segmentation fault just
before giving the Access-Accept EAP-Success back to the switch. I
have searched the archives for a solution but not found help to sort
my
problem out.
See doc/bugs
I don't understand is why the modcall[authorise] appear often in
request
processing before modcall[authenticate]. I thought the order was to
authenticate a user and then once we are sure they are who they say
they
are then we authorise them to use the network.
Due to historical issues, FreeRADIUS has pre-authenticate,
authenticate, and post-authenticate. The pre-authenticate is called
authorize.
The sections could just as easily be called foo, bar, and baz.
It makes no difference to the operation of the server.
Alan DeKok.
-
List info/subscribe/unsubscribe? See
http://www.freeradius.org/list/users.html
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
FW: TTLS and PAP
Folks,
I'm trying to get TTLS/PAP working using freeradius 1.0.4. I must have
it configured incorrectly because its giving a Segmentation fault just
before giving the Access-Accept EAP-Success back to the switch. I
have searched the archives for a solution but not found help to sort my
problem out.
I have played around with the configuration but don't fully understand
what I'm doing. Could someone point me to a place where I can read and
understand how the authenticate and autorize sections work. The
explanation in the radiusd.conf file don't seem to click with me.
I don't understand is why the modcall[authorise] appear often in request
processing before modcall[authenticate]. I thought the order was to
authenticate a user and then once we are sure they are who they say they
are then we authorise them to use the network.
Thanks for any help,
Martin.
radiusd.conf
authenticate {
Auth-Type PAP {
pap
}
eap
}
authorize {
preprocess
eap
files
}
Users file..
Client certificate Auth-Type := Local, User-Password == bradley
Service-Type = Framed-User,
Framed-Compression = Van-Jacobsen-TCP-IP
Processing the authorize section of radiusd.conf
modcall: entering group authorize for request 3
modcall[authorize]: module preprocess returns ok for request 3
users: Matched entry DEFAULT at line 162
modcall[authorize]: module files returns ok for request 3
rlm_eap: EAP packet type response id 34 length 200
rlm_eap: No EAP Start, assuming it's an on-going EAP conversation
modcall[authorize]: module eap returns updated for request 3
modcall: group authorize returns updated for request 3
rad_check_password: Found Auth-Type System
rad_check_password: Found Auth-Type EAP
Warning: Found 2 auth-types on request for user 'anonymous'
auth: type EAP
Processing the authenticate section of radiusd.conf
modcall: entering group authenticate for request 3
rlm_eap: Request found, released from the list
rlm_eap: EAP/ttls
rlm_eap: processing type ttls
rlm_eap_ttls: Authenticate
rlm_eap_tls: processing TLS
rlm_eap_tls: Length Included
eaptls_verify returned 11
TLS_accept: SSLv3 read client key exchange A
TLS_accept: SSLv3 read finished A
TLS_accept: SSLv3 write change cipher spec A
TLS_accept: SSLv3 write finished A
TLS_accept: SSLv3 flush data
(other): SSL negotiation finished successfully
SSL Connection Established
eaptls_process returned 13
modcall[authenticate]: module eap returns handled for request 3
modcall: group authenticate returns handled for request 3
Sending Access-Challenge of id 34 to 10.230.199.248:1126
EAP-Message =
0x0123003d1580003314030100010116030100288b7a33f454f760f4cddff2f95941
b215a6f3d73b5e422d1744b2201bee31448f10dc78f33f354476
Message-Authenticator = 0x
State = 0x49b28c5e2307f384db00487f11336474
Going to the next request
Waking up in 5 seconds...
rad_recv: Access-Request packet from host 10.230.199.248:1126, id=35,
length=248
User-Name = anonymous
NAS-IP-Address = 10.230.199.248
NAS-Port = 2
State = 0x49b28c5e2307f384db00487f11336474
Calling-Station-Id = 00:06:5b:d6:ff:24
NAS-Identifier = radius-netgear
NAS-Port-Type = Ethernet
EAP-Message =
0x02230078150017030100189e2c7d7fea093fe36d2ad301f92cc2ef4cba50563b00a0a8
1703010050b5955c43a5cd51375cebde00ed386a2f4273385aa3f6b0b2c6f7e15b73a75e
e8f64e15abdca0a875fd3408d3ce811a76580cee45fc540215f84bcc2f99a95cc5199a36
da952c0a76243f7f7645f4327b
Message-Authenticator = 0x3ddd5d8d65f10f4a26c7db7ab52a96db
X-Ascend-Token-Idle = 1
Processing the authorize section of radiusd.conf
modcall: entering group authorize for request 4
modcall[authorize]: module preprocess returns ok for request 4
users: Matched entry DEFAULT at line 162
modcall[authorize]: module files returns ok for request 4
rlm_eap: EAP packet type response id 35 length 120
rlm_eap: No EAP Start, assuming it's an on-going EAP conversation
modcall[authorize]: module eap returns updated for request 4
modcall: group authorize returns updated for request 4
rad_check_password: Found Auth-Type System
rad_check_password: Found Auth-Type EAP
Warning: Found 2 auth-types on request for user 'anonymous'
auth: type EAP
Processing the authenticate section of radiusd.conf
modcall: entering group authenticate for request 4
rlm_eap: Request found, released from the list
rlm_eap: EAP/ttls
rlm_eap: processing type ttls
rlm_eap_ttls: Authenticate
rlm_eap_tls: processing TLS
eaptls_verify returned 7
rlm_eap_tls: Done initial handshake
eaptls_process returned 7
rlm_eap_ttls: Session established. Proceeding to decode tunneled
attributes.
Processing the authorize section of radiusd.conf
modcall: entering group authorize for request 4
Active Directory and mschapv2
Folks, I'd like freeradius to authenticate me to an Active directory using mschapv2. Can it do that currently from the code it seems that it can only do this for passwords stored locally. Heres a comment from src/modules/rlm_mschap.c /* * Do the MS-CHAP stuff. * * This function is here so that all of the MS-CHAP related * authentication is in one place, and we can perhaps later replace * it with code to call winbindd, or something similar. */ I'm sorry if you seen this mail twice. Martin - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Active Directory and mschapv2
Stéphane, Thanks for the help. Martin -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of DELORT Stephane Sent: 20 May 2005 12:48 To: freeradius-users@lists.freeradius.org Subject: RE: Active Directory and mschapv2 Hello Martin, You can use ntlm_auth to authenticate against an AD base. First, test ntml_auth (part of winbind) from the command line and then, put your line in radiusd.conf. Take a look at the default file to see an example of this line. Regards, Stéphane -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] la part de [EMAIL PROTECTED] Envoyé : vendredi 20 mai 2005 12:48 À : freeradius-users@lists.freeradius.org Objet : Active Directory and mschapv2 Folks, I'd like freeradius to authenticate me to an Active directory using mschapv2. Can it do that currently from the code it seems that it can only do this for passwords stored locally. Heres a comment from src/modules/rlm_mschap.c /* * Do the MS-CHAP stuff. * * This function is here so that all of the MS-CHAP related * authentication is in one place, and we can perhaps later replace * it with code to call winbindd, or something similar. */ I'm sorry if you seen this mail twice. Martin - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: EAP-MD5 Access Challenge.
Alan, I'm not using an NAS to send the Access-Request. I'm using radeapclient. It is causing me a problem it is just not what is supposed to happen I think. freeradius version 1.0.1 I had tried to attach some configuration files but they bounced off the mail server saying Message is bigger than 65536 bytes - refused. Martin. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alan DeKok Sent: 20 January 2005 19:52 To: freeradius-users@lists.freeradius.org Subject: Re: EAP-MD5 Access Challenge. [EMAIL PROTECTED] wrote: Thanks for the suggestion. I tried it but I'm still getting attributes in the Access-Challenge packet. The output is shown below. Is it causing a problem on the NAS? Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: EAP-MD5 Access Challenge.
Oops. I meant to say It is NOT causing me a problem it is just not what is supposed to happen I think. Sorry Martin. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: 21 January 2005 10:12 To: freeradius-users@lists.freeradius.org Subject: RE: EAP-MD5 Access Challenge. Alan, I'm not using an NAS to send the Access-Request. I'm using radeapclient. It is causing me a problem it is just not what is supposed to happen I think. freeradius version 1.0.1 I had tried to attach some configuration files but they bounced off the mail server saying Message is bigger than 65536 bytes - refused. Martin. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alan DeKok Sent: 20 January 2005 19:52 To: freeradius-users@lists.freeradius.org Subject: Re: EAP-MD5 Access Challenge. [EMAIL PROTECTED] wrote: Thanks for the suggestion. I tried it but I'm still getting attributes in the Access-Challenge packet. The output is shown below. Is it causing a problem on the NAS? Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: EAP-MD5 Access Challenge.
Alan, This is not causing me a problem at all. I was just wondering what I had wrong in my configuration to cause it to happen. Martin 5.44. Table of Attributes The following table provides a guide to which attributes may be found in which kinds of packets, and in what quantity. Request Accept Reject Challenge #Attribute 0-1 0-1 001 User-Name 0-1 0002 User-Password [Note 1] 0-1 0003 CHAP-Password [Note 1] 0-1 0004 NAS-IP-Address [Note 2] 0-1 0005 NAS-Port 0-1 0-1 006 Service-Type 0-1 0-1 007 Framed-Protocol 0-1 0-1 008 Framed-IP-Address 0-1 0-1 009 Framed-IP-Netmask 0 0-1 00 10 Framed-Routing 0 0+ 00 11 Filter-Id 0-1 0-1 00 12 Framed-MTU 0+0+ 00 13 Framed-Compression 0+0+ 00 14 Login-IP-Host 0 0-1 00 15 Login-Service 0 0-1 00 16 Login-TCP-Port 0 0+ 0+ 0+ 18 Reply-Message 0-1 0-1 00 19 Callback-Number 0 0-1 00 20 Callback-Id 0 0+ 00 22 Framed-Route 0 0-1 00 23 Framed-IPX-Network 0-1 0-1 00-1 24 State [Note 1] 0 0+ 00 25 Class 0+0+ 00+ 26 Vendor-Specific 0 0-1 00-1 27 Session-Timeout 0 0-1 00-1 28 Idle-Timeout 0 0-1 00 29 Termination-Action 0-1 000 30 Called-Station-Id 0-1 000 31 Calling-Station-Id 0-1 000 32 NAS-Identifier [Note 2] 0+0+ 0+ 0+ 33 Proxy-State 0-1 0-1 00 34 Login-LAT-Service 0-1 0-1 00 35 Login-LAT-Node Rigney, et al. Standards Track[Page 63] RFC 2865 RADIUSJune 2000 0-1 0-1 00 36 Login-LAT-Group 0 0-1 00 37 Framed-AppleTalk-Link 0 0+ 00 38 Framed-AppleTalk-Network 0 0-1 00 39 Framed-AppleTalk-Zone 0-1 000 60 CHAP-Challenge 0-1 000 61 NAS-Port-Type 0-1 0-1 00 62 Port-Limit 0-1 0-1 00 63 Login-LAT-Port Request Accept Reject Challenge #Attribute -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alan DeKok Sent: 21 January 2005 15:40 To: freeradius-users@lists.freeradius.org Subject: Re: EAP-MD5 Access Challenge. [EMAIL PROTECTED] wrote: It is causing me a problem it is just not what is supposed to happen I think. What in the documentation led you to think that? Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
EAP-MD5 Access Challenge.
Hello all, I was trying to get EAP-MD5 authentication working with freeradius. I'm using radeapclient to send in the request. I have a user in my users file as shown below. DNIS:123456789 Auth-Type := Local, User-Password == marty Service-Type = Framed-User, Framed-Protocol = PPP, Framed-IP-Address = 1.2.3.4, Framed-IP-Netmask = 255.255.255.0, Framed-Routing = Broadcast-Listen, Framed-Filter-Id = std.ppp, Framed-MTU = 1500, Framed-Compression = Van-Jacobsen-TCP-IP I'm sending in the request using radeapclient with the details below. User-Name = DNIS:123456789 EAP-MD5-Password = marty NAS-IP-Address = 10.230.199.211 EAP-Code = Response EAP-Id = 210 EAP-Type-Identity = DNIS:123456789 Message-Authenticator = 0x00 NAS-Port = 0 ./radeapclient -x 10.230.199.211 auth SharedSecret ~/EAP/req.txt It works and I get an Access Accept out with EAP Success. However the Access-Challenge that freeradius sends me back contains all the connection attributes as the output from radeapclient below shows. rad_recv: Access-Challenge packet from host 10.230.199.211:1812, id=140, length=131 Service-Type = Framed-User Framed-Protocol = PPP Framed-IP-Address = 1.2.3.4 Framed-IP-Netmask = 255.255.255.0 Framed-Routing = Broadcast-Listen Filter-Id = std.ppp Framed-MTU = 1500 Framed-Compression = Van-Jacobson-TCP-IP EAP-Message = 0x01d300160410c85c14878e1b23ee8b5703ad2d916a25 Message-Authenticator = 0x39668b64ccf66b262e280f3d5c965e3c State = 0x28b0e037604ae483026cf00352a72fa4 I know I have most likely mis-configured something to cause freeradius to send these connection details out in a Challenge packet when it should not. Does anyone know what I might have wrong in my configuration. Also does anyone know why I have to run the radeapclient program from the freeradius-1.0.1/src/modules/rlm_eap directory where I complied the code. Thanks for any help, Martin - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
FW: EAP-Message attribute.
Hello, I think Freeradius does not comply with RFC3579 with respect of the EAP Start packet. RFC 3579 says that an empty EAP-Message attribute signifies the EAP-Start. To me this means the following attribute hex 0x4f 0x02 An evaluation copy of Steel Belted RADIUS takes 0x4f 0x02 as a valid EAP start, on receipt it sends back a Access-Challenge with a EAP-Request for Identity. FreeRadius does not accept this 2 byte hex attribute as an EAP-start but needs 0x4f 0x04 0x01 0x01. If I send the above 4 byte EAP-Message to Steel Belted returns a reject and logs that it got a invalid EAP-Message. If Free Radius is sent the short two byte EAP-start that Steel Belted likes then it does not interpret it as an EAP-Start. I just wanted to share my findings. Do the freeradius developers have a GPL software tool that can be used to generate RADIUS requests? Thanks, Martin. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: 05 May 2004 10:59 To: [EMAIL PROTECTED] Subject: RE: EAP-Message attribute. Alan, The problem I was having is fixed in the latest CVS snapshot. The old version of eap.c was printing out the EAP code as the identity. Nothing. Use the latest CVS snapshot. 0.9.0 is *very* old. DEBUG2( rlm_eap: EAP packet type %s id %d length %d, eap_types[eap_msg-strvalue[0]], eap_msg-strvalue[1], (eap_msg-strvalue[2] 8) | eap_msg-strvalue[3]); The new (correct) version uses DEBUG2( rlm_eap: EAP packet type %s id %d length %d, eap_codes[eap_msg-strvalue[0]], eap_msg-strvalue[1], eap_msg-length); That is were my confusion came from. Thanks very much. Martin. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alan DeKok Sent: 04 May 2004 20:58 To: [EMAIL PROTECTED] Subject: Re: EAP-Message attribute. [EMAIL PROTECTED] wrote: Question 1. RFC 3579 states that EAP-Start is indicated by sending an EAP-Message attribute with a length of 2 (no data). I interpret this to be the following two bytes '0x49 0x02'. Hmm... I think that's a typo, or, at least, it's not the way most clients work. But when I send a packet containing such an attribute to freeradius it does not see it as an EAP start. Below is the packet that was sent to free radius ... rad_recv: Access-Request packet from host 10.230.199.211:33118, id=1, length=92 User-Name = DNIS:123456789 NAS-IP-Address = 1.2.3.4 Service-Type = Call-Check Called-Station-Id = 0123456789 Calling-Station-Id = 0123456789 EAP-Message = 0x Which is an empty EAP message. It appears to satisfy the RFC's, but I don't think any client behaves that way. Most EAP clients use a two-byte EAP packet, which means a RADIUS EAP-Message of length 4. To get around this I send the EAP-Message 0x4f 0x0c 0x01 0xff rlm_eap: EAP packet type identity id 255 length 0 rlm_eap: Got EAP_START message modcall[authorize]: module eap returns handled Am I reading the RFC wrong? I don't think so, but in ~2 years of using the EAP module, this has never come up before. I send the following EAP-Message Radius-Attribute = 0x 4f 0c 02 ff 00 0a 01 68 65 6c 6c 6f This is a EAP-Message with code=Response and Type = Identity, = however the debug states that the type is=20 notification. What am I doing wrong? Nothing. Use the latest CVS snapshot. 0.9.0 is *very* old. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: EAP-Message attribute.
Alan, The problem I was having is fixed in the latest CVS snapshot. The old version of eap.c was printing out the EAP code as the identity. Nothing. Use the latest CVS snapshot. 0.9.0 is *very* old. DEBUG2( rlm_eap: EAP packet type %s id %d length %d, eap_types[eap_msg-strvalue[0]], eap_msg-strvalue[1], (eap_msg-strvalue[2] 8) | eap_msg-strvalue[3]); The new (correct) version uses DEBUG2( rlm_eap: EAP packet type %s id %d length %d, eap_codes[eap_msg-strvalue[0]], eap_msg-strvalue[1], eap_msg-length); That is were my confusion came from. Thanks very much. Martin. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alan DeKok Sent: 04 May 2004 20:58 To: [EMAIL PROTECTED] Subject: Re: EAP-Message attribute. [EMAIL PROTECTED] wrote: Question 1. RFC 3579 states that EAP-Start is indicated by sending an EAP-Message attribute with a length of 2 (no data). I interpret this to be the following two bytes '0x49 0x02'. Hmm... I think that's a typo, or, at least, it's not the way most clients work. But when I send a packet containing such an attribute to freeradius it does not see it as an EAP start. Below is the packet that was sent to free radius ... rad_recv: Access-Request packet from host 10.230.199.211:33118, id=1, length=92 User-Name = DNIS:123456789 NAS-IP-Address = 1.2.3.4 Service-Type = Call-Check Called-Station-Id = 0123456789 Calling-Station-Id = 0123456789 EAP-Message = 0x Which is an empty EAP message. It appears to satisfy the RFC's, but I don't think any client behaves that way. Most EAP clients use a two-byte EAP packet, which means a RADIUS EAP-Message of length 4. To get around this I send the EAP-Message 0x4f 0x0c 0x01 0xff rlm_eap: EAP packet type identity id 255 length 0 rlm_eap: Got EAP_START message modcall[authorize]: module eap returns handled Am I reading the RFC wrong? I don't think so, but in ~2 years of using the EAP module, this has never come up before. I send the following EAP-Message Radius-Attribute = 0x 4f 0c 02 ff 00 0a 01 68 65 6c 6c 6f This is a EAP-Message with code=Response and Type = Identity, = however the debug states that the type is=20 notification. What am I doing wrong? Nothing. Use the latest CVS snapshot. 0.9.0 is *very* old. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
EAP-Message attribute.
Hello all, I have two EAP related questions when running radiusd: FreeRADIUS Version 0.9.0 running in debug mode -X. Question 1. RFC 3579 states that EAP-Start is indicated by sending an EAP-Message attribute with a length of 2 (no data). I interpret this to be the following two bytes '0x49 0x02'. But when I send a packet containing such an attribute to freeradius it does not see it as an EAP start. Below is the packet that was sent to free radius sendwait: Sending rathPacket: 01 01 00 5c 62 72 61 64 6c 65 79 00 00 00 00 00 00 00 00 00 01 10 44 4e 49 53 3a 31 32 33 34 35 36 37 38 39 04 06 01 02 03 04 06 06 00 00 00 0a 1e 0c 30 31 32 33 34 35 36 37 38 39 1f 0c 30 31 32 33 34 35 36 37 38 39 4f 02 50 12 f8 62 e2 00 52 d1 bf 52 c8 0f 34 80 f6 cc b8 cb rad_recv: Access-Request packet from host 10.230.199.211:33118, id=1, length=92 User-Name = DNIS:123456789 NAS-IP-Address = 1.2.3.4 Service-Type = Call-Check Called-Station-Id = 0123456789 Calling-Station-Id = 0123456789 EAP-Message = 0x Message-Authenticator = 0xf862e20052d1bf52c80f3480f6ccb8cb modcall: entering group authorize modcall[authorize]: module preprocess returns ok modcall[authorize]: module chap returns noop rlm_eap: Unknown EAP packet rlm_eap: EAP Start not found modcall[authorize]: module eap returns updated rlm_realm: No '@' in User-Name = DNIS:123456789, looking up realm NULL rlm_realm: No such realm NULL modcall[authorize]: module suffix returns noop users: Matched DNIS:123456789 at 154 modcall[authorize]: module files returns ok modcall[authorize]: module mschap returns noop modcall: group authorize returns updated rad_check_password: Found Auth-Type Local auth: type Local auth: No User-Password or CHAP-Password attribute in the request auth: Failed to validate the user. Delaying request 1 for 1 seconds Finished request 1 Going to the next request --- Walking the entire request list --- Waking up in 1 seconds... --- Walking the entire request list --- Waking up in 1 seconds... --- Walking the entire request list --- Sending Access-Reject of id 1 to 10.230.199.211:33118 Waking up in 4 seconds... --- Walking the entire request list --- Cleaning up request 1 ID 1 with timestamp 4097bd99 Nothing to do. Sleeping until we see a request. To get around this I send the EAP-Message 0x4f 0x0c 0x01 0xff rlm_eap: EAP packet type identity id 255 length 0 rlm_eap: Got EAP_START message modcall[authorize]: module eap returns handled Am I reading the RFC wrong? Question 2. I send the following EAP-Message Radius-Attribute = 0x 4f 0c 02 ff 00 0a 01 68 65 6c 6c 6f This is a EAP-Message with code=Response and Type = Identity, however the debug states that the type is notification. What am I doing wrong? rlm_eap: EAP packet type notification id 255 length 10 rad_recv: Access-Request packet from host 10.230.199.211:33118, id=1, length=102 User-Name = DNIS:123456789 NAS-IP-Address = 1.2.3.4 Service-Type = Call-Check Called-Station-Id = 0123456789 Calling-Station-Id = 0123456789 EAP-Message = 0x02ff000a0168656c6c6f Message-Authenticator = 0x2d0593fd6c29c9bed3b2147ada26d942 modcall: entering group authorize modcall[authorize]: module preprocess returns ok modcall[authorize]: module chap returns noop rlm_eap: EAP packet type notification id 255 length 10 rlm_eap: EAP Start not found modcall[authorize]: module eap returns updated rlm_realm: No '@' in User-Name = DNIS:123456789, looking up realm NULL rlm_realm: No such realm NULL modcall[authorize]: module suffix returns noop users: Matched DNIS:123456789 at 154 modcall[authorize]: module files returns ok modcall[authorize]: module mschap returns noop modcall: group authorize returns updated rad_check_password: Found Auth-Type Local auth: type Local auth: No User-Password or CHAP-Password attribute in the request auth: Failed to validate the user. Delaying request 4 for 1 seconds Finished request 4 Going to the next request --- Walking the entire request list --- Waking up in 1 seconds... --- Walking the entire request list --- Waking up in 1 seconds... --- Walking the entire request list --- Sending Access-Reject of id 1 to 10.230.199.211:33118 Waking up in 4 seconds... --- Walking the entire request list --- Cleaning up request 4 ID 1 with timestamp 4097bec2 Nothing to do. Sleeping until we see a request. My understanding of EAP Freeradius is limited but getting better. Any help is appreciated. Thanks, Martin Bradley Riverside Tower, Belfast, BT1 3BT - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
