Re: Fragmented EAP frames was My problem with PEAP
Thanks Alan, Alan DeKok wrote: Bill Reid <[EMAIL PROTECTED]> wrote: I grabbed the latest snapshot on friday. Recompiled. Reconfigured the default radiusd.conf file to use eap/peap. I am still seeing fragmented Access Challenge packets. However the first access challenge was not fragmented. The ones after that were. Please don't call the packets "fragmented". They're not. As seen in the debug log you posted, the server is calling the EAP module twice for authentication, and there are TWO eap packets in the RADIUS response, not one "fragmented" packet. I will try to watch my terminology cuase you are right. I haven't seen that behaviour when I use PEAP, and so far there haven't been reports from anyone else, either. I will install the same snapshot on a FreeBSD box (currently it is on debian) and see if the behavior is the same. then the packet trace is irrelevant. We already know that the problem is in the RADIUS server, as it's debug logs are telling you there's a problem. Find out WHY the EAP module is being called twice. Nothing else is relevant. I understand. I will do my best. 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: Fragmented EAP frames was My problem with PEAP
Bill Reid <[EMAIL PROTECTED]> wrote: > I grabbed the latest snapshot on friday. Recompiled. Reconfigured the > default radiusd.conf file to use eap/peap. > > I am still seeing fragmented Access Challenge packets. However the > first access challenge was not fragmented. The ones after that were. Please don't call the packets "fragmented". They're not. As seen in the debug log you posted, the server is calling the EAP module twice for authentication, and there are TWO eap packets in the RADIUS response, not one "fragmented" packet. I haven't seen that behaviour when I use PEAP, and so far there haven't been reports from anyone else, either. > Content-Disposition: attachment; > filename="cisco_dump_tunnel_radius" That's nice, but if the RADIUS server is still calling authenticate twice for the EAP module, then the packet trace is irrelevant. We already know that the problem is in the RADIUS server, as it's debug logs are telling you there's a problem. Find out WHY the EAP module is being called twice. Nothing else is relevant. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Fragmented EAP frames was My problem with PEAP
Hmm, My other message did not make it through. Perhaps people are sick of hearing about this :) I grabbed the latest snapshot on friday. Recompiled. Reconfigured the default radiusd.conf file to use eap/peap. I am still seeing fragmented Access Challenge packets. However the first access challenge was not fragmented. The ones after that were. My config, dumps and debug are included. radtest works with the unchanged default radiusd.conf returning stuff from the users file. Sending Access-Request of id 123 to 127.0.0.1:1812 User-Name = "wer" User-Password = "testtest" NAS-IP-Address = hotspot NAS-Port = 1 rad_recv: Access-Accept packet from host 127.0.0.1:1812, id=123, length=37 User-Name = "wer" Framed-IP-Address = xxx.xxx.xxx.31 Framed-IP-Netmask = 255.255.255.255 - Edit 1 to radiusd.conf: PEAP Upon enabling peap (and thusly tls), radtest still works, but I get an access reject when attempting to use peap. I had to configure tls right? I used my certs. I changed the default type for eap to peap and the default type for peap to mschapv2 At one point I added copy_request_to_tunnel to peap {} because I think I misinterpreted the debug below. I think that change was moot though. I am back to a similar fragmented frame problem as well though I think the conversation made it further. The first access challenge is not fragmented. However the second challenge is severely fragmented The supplicant says attempting to "authenticate the user" instead of just "validating user". So I think the the supplicant is responding to the challenge now with another request. However the next challenge is severely fragmented. I am suspect of these lines, which is why at one point I tried the copy_request_to_tunnel (radiusd.conf Edit 2) but realized it probably didn't matter at this point (radiusd.conf Edit 3). rlm_eap_tls: <<< TLS 1.0 Alert [length 0002], fatal access_denied TLS Alert read:fatal:access denied -=Bill cisco_dump_tunnel_radius Description: Binary data Starting - reading configuration files ... reread_config: reading radiusd.conf Config: including file: /usr/local/etc/raddb/proxy.conf Config: including file: /usr/local/etc/raddb/clients.conf Config: including file: /usr/local/etc/raddb/snmp.conf Config: including file: /usr/local/etc/raddb/sql.conf main: prefix = "/usr/local" main: localstatedir = "/usr/local/var" main: logdir = "/usr/local/var/log/radius" main: libdir = "/usr/local/lib" main: radacctdir = "/usr/local/var/log/radius/radacct" main: hostname_lookups = no main: max_request_time = 30 main: cleanup_delay = 5 main: max_requests = 1024 main: delete_blocked_requests = 0 main: port = 0 main: allow_core_dumps = no main: log_stripped_names = no main: log_file = "/usr/local/var/log/radius/radius.log" main: log_auth = no main: log_auth_badpass = no main: log_auth_goodpass = no main: pidfile = "/usr/local/var/run/radiusd/radiusd.pid" main: user = "(null)" main: group = "(null)" main: usercollide = no main: lower_user = "no" main: lower_pass = "no" main: nospace_user = "no" main: nospace_pass = "no" main: checkrad = "/usr/local/sbin/checkrad" main: proxy_requests = yes proxy: retry_delay = 5 proxy: retry_count = 3 proxy: synchronous = no proxy: default_fallback = yes proxy: dead_time = 120 proxy: post_proxy_authorize = yes proxy: wake_all_if_all_dead = no security: max_attributes = 200 security: reject_delay = 1 security: status_server = no main: debug_level = 0 read_config_files: reading dictionary read_config_files: reading naslist Using deprecated naslist file. Support for this will go away soon. read_config_files: reading clients Using deprecated clients file. Support for this will go away soon. read_config_files: reading realms Using deprecated realms file. Support for this will go away soon. radiusd: entering modules setup Module: Library search path is /usr/local/lib Module: Loaded expr Module: Instantiated expr (expr) Module: Loaded PAP pap: encryption_scheme = "crypt" Module: Instantiated pap (pap) Module: Loaded CHAP Module: Instantiated chap (chap) Module: Loaded MS-CHAP mschap: use_mppe = yes mschap: require_encryption = no mschap: require_strong = no mschap: passwd = "(null)" mschap: authtype = "MS-CHAP" Module: Instantiated mschap (mschap) Module: Loaded System unix: cache = no unix: passwd = "(null)" unix: shadow = "(null)" unix: group = "(null)" unix: radwtmp = "/usr/local/var/log/radius/radwtmp" unix: usegroup = no unix: cache_reload = 600 Module: Instantiated unix (unix) Module: Loaded eap eap: default_eap_type = "peap" eap: timer_expire = 60 eap: ignore_unknown_eap_types = no rlm_eap: Loaded and initialized type md5 rlm_eap: Loaded and initialized type leap tls: rsa_key_exchange = no tls: dh_key_exchange = yes tls: rsa_key_length = 512 tls: dh_key_length = 512 tls: verify_depth = 0 tls: CA
Re: My problem with PEAP
Bill Reid <[EMAIL PROTECTED]> wrote: > I promiss I am using that radiusd.conf. I started from scratch this time. Did you start from the DEFAULT radiusd.conf? If it doesn't work in the default configuration, then something else is wrong, and no amount of editing the default configuration will work. If it does work in the default configuration, then keep back-up copies of it, and slowly edit it bit by bit, until you see the problem. The last edit will then be the cause of the problem, and you can post the changes to the list. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: My problem with PEAP
Alan DeKok wrote: William E Reid <[EMAIL PROTECTED]> wrote: I reconfigured from the default radiusd.conf file and did this test again with the same strange results from peap. I really don't know what to tell you. Are you *sure* it's using the 'radiusd.conf' file you think it's using? I promiss I am using that radiusd.conf. I started from scratch this time. Try using a fresh install of the server... No one else see what you're seeing, so I can only assume it's a site local problem. I will grab the latest snapshot and recompile and retest. Thanks Alan. -=Bill 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: My problem with PEAP
William E Reid <[EMAIL PROTECTED]> wrote: > I reconfigured from the default radiusd.conf file and did this > test again with the same strange results from peap. I really don't know what to tell you. Are you *sure* it's using the 'radiusd.conf' file you think it's using? Try using a fresh install of the server... No one else see what you're seeing, so I can only assume it's a site local problem. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: My problem with PEAP
Hey guys, I reconfigured from the default radiusd.conf file and did this test again with the same strange results from peap. I could certainly be doing something stupid and would appreciate any further feedback. I have included my radiusd.conf file and a new tcpdump from the server. Sorry for the attachments. Best wishes, -=Bill Michael Griego wrote: > On Wed, 2003-11-19 at 13:09, Alan DeKok wrote: > > From the debug output, it looks like you've managed to make the > > server call the EAP module *twice* for the request, during the > > "authenticate" stage. I have no clue how you managed to do this, but > > it's definitely wrong. > > That's exactly what I'm seeing. > > Bill, You didn't by chance put "authorize" or an Autz-Type in the > "authenticate" section did you? Based on the trace, it really looks > like this is what happened. The server jumps into the authorize section > upon receiving the request (as normal), then begins the authenticate > phase, but it then jumps BACK into an authorize block again before > coming back out of all the mess. > I double checked the syntax and don't think I was doing anything like above. > > -- > > --Mike > > --- > Michael Griego > Wireless LAN Project Manager > The University of Texas at Dallas > > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html Ôò¡ ê½?íY È È øf 0¶À~ E ºú >?tÑ?BØ â ¦UT ?/ssÒ°©+¶°?Ûy÷.Ywer ssid=Ntelos_AP_01Ñ?B000dbda1f1e9000dbd05196d uncklejam.cstone.net % x= O [EMAIL PROTECTED]@N¯Ø Ñ?Bâ bgúT Zm^zÖ?ìǾÚ-?·µsO PÎé|¯ â ÏV}TlÐÚá?j×ß)?Í»ÞÏ;O Cùj?ñ|~Üûñ Üóprefix = /usr/local exec_prefix = ${prefix} sysconfdir = ${prefix}/etc localstatedir = ${prefix}/var sbindir = ${exec_prefix}/sbin logdir = ${localstatedir}/log/radius raddbdir = ${sysconfdir}/raddb radacctdir = ${logdir}/radacct confdir = ${raddbdir} run_dir = ${localstatedir}/run/radiusd log_file = ${logdir}/radius.log libdir = ${exec_prefix}/lib pidfile = ${run_dir}/radiusd.pid max_request_time = 30 delete_blocked_requests = no cleanup_delay = 5 max_requests = 1024 bind_address = * port = 0 hostname_lookups = no allow_core_dumps = no regular_expressions = yes extended_expressions= yes log_stripped_names = no log_auth = yes log_auth_badpass = yes log_auth_goodpass = no usercollide = yes lower_user = before lower_pass = no nospace_user = no nospace_pass = no checkrad = ${sbindir}/checkrad security { max_attributes = 200 reject_delay = 1 status_server = no } proxy_requests = no $INCLUDE ${confdir}/proxy.conf $INCLUDE ${confdir}/clients.conf snmp= no $INCLUDE ${confdir}/snmp.conf thread pool { start_servers = 5 max_servers = 32 min_spare_servers = 3 max_spare_servers = 10 max_requests_per_server = 0 } modules { pap { encryption_scheme = crypt } chap { authtype = CHAP } eap { default_eap_type = peap timer_expire = 60 ignore_unknown_eap_types = no md5 { } leap { } tls { private_key_password = thinngything private_key_file = /usr/local/etc/raddb/blah.key certificate_file = /usr/local/etc/raddb/blah.crt CA_file = /usr/local/etc/raddb/blah.cacrt dh_file = /usr/local/etc/raddb/my_imap.dh random_file = /usr/local/etc/raddb/random fragment_size = 1024 include_length = yes check_crl = yes } peap { default_eap_type = mschapv2 } mschapv2 { } } mschap { authtype = MS-CHAP } realm suffix { format = suffix delimiter = "@" } preprocess { huntgroups = ${confdir}/huntgroups hints = ${confdir}/hints with_ascend_hack = no ascend_channels_per_line = 23 with_ntdomain_hack = yes with_specialix_jetstream_hack = no with_cisco_vsa_hack = yes } files { usersfile = ${confdir}/users acctusersfile = ${confdir}/acct_users compat = no } detail { detailfile = ${radacctdir}/%{Client-IP-Address}/detail-%Y%m%d detailperm = 0600 } detail auth_log { detailfile = ${radacctdir}/%{Client-IP-Address}/auth-detail-%Y%m%d deta
Re: My problem with PEAP
On Wed, 2003-11-19 at 13:09, Alan DeKok wrote: > From the debug output, it looks like you've managed to make the > server call the EAP module *twice* for the request, during the > "authenticate" stage. I have no clue how you managed to do this, but > it's definitely wrong. That's exactly what I'm seeing. Bill, You didn't by chance put "authorize" or an Autz-Type in the "authenticate" section did you? Based on the trace, it really looks like this is what happened. The server jumps into the authorize section upon receiving the request (as normal), then begins the authenticate phase, but it then jumps BACK into an authorize block again before coming back out of all the mess. -- --Mike --- Michael Griego Wireless LAN Project Manager The University of Texas at Dallas - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: My problem with PEAP
Bill Reid <[EMAIL PROTECTED]> wrote: > I continue to have a problem using peap with > freeradius-snapshot-20031110. From what I have read about EAP, and > from my discussions with others on this list, I believe I am seeing a > problem from freeradius. I've looked at your packet trace, and there are two EAP packets (and therefore PEAP packets) in the Access-Challenge. I've never seen this before, so I suspect it's a local configuration issue. Still, the server should be fixed to NOT do this. From the debug output, it looks like you've managed to make the server call the EAP module *twice* for the request, during the "authenticate" stage. I have no clue how you managed to do this, but it's definitely wrong. What did you edit in the server configuration to make it do this? Under normal circumstances, PEAP should work "out of the box", by simple configuring the peap{} module section, and starting the server. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: My problem with PEAP
I am asking the dumb questions here! No I don't. thanks Mike. -=Bill Michael Griego wrote: Umm... dumb question, but you don't have "eap" listed in the authenticate section of your radiusd.conf file twice do you? --Mike On Wed, 2003-11-19 at 12:31, Bill Reid wrote: Hey everyone, I continue to have a problem using peap with freeradius-snapshot-20031110. From what I have read about EAP, and from my discussions with others on this list, I believe I am seeing a problem from freeradius. Please correct me if I am wrong. According to the documentation in ./doc/rlm_eap. The client is not responding to step 6 "Access Challenge" from the radius server. I can see the Radius packet making it to the client. The only thing I can find that is odd about the challenge is that there are two eap portions of the frame. My hope is that the client is ignoring the frame because of this. Since there is no response from the client(supplicant) I do not get an EAP-Success/EAP-failure and begin to negotiate any ssl/wep stuff. So I don't even think I am verifying the server using the installed CERT at this point. In other words, I don't suspect I have a key/cert problem yet :). I have included the frames in this email. They were captured on the radius server side. Note there are two separate attempts from the client to authenticate itself. I am questioning either of the Access Challenge frames. I would love it if someone could look at these frames and tell me if they are correct (that freeradius is creating them properly). Below the message Authenticator is similar to 0x00. In the frame sent to the supplicant, the second portion EAP type 79 does not have the authenticator, the first portion EAP type 79 does have the Message Authenticator and is filled with a value other then 0x0. I am guessing that is where the hash for the password goes. Any help would be greatly appreciated. Here is the output of radiusd -Xxx Tue Nov 18 14:52:33 2003 : Info: Starting - reading configuration files ... Tue Nov 18 14:52:33 2003 : Debug: reread_config: reading radiusd.conf Tue Nov 18 14:52:33 2003 : Debug: Config: including file: /usr/local/etc/raddb/clients.conf Tue Nov 18 14:52:33 2003 : Debug: Config: including file: /usr/local/etc/raddb/snmp.conf Tue Nov 18 14:52:33 2003 : Debug: main: prefix = "/usr/local" Tue Nov 18 14:52:33 2003 : Debug: main: localstatedir = "/usr/local/var" Tue Nov 18 14:52:33 2003 : Debug: main: logdir = "/var/log/radius" Tue Nov 18 14:52:33 2003 : Debug: main: libdir = "/usr/local/lib" Tue Nov 18 14:52:33 2003 : Debug: main: radacctdir = "/var/log/radius/radacct" Tue Nov 18 14:52:33 2003 : Debug: main: hostname_lookups = no Tue Nov 18 14:52:33 2003 : Debug: main: max_request_time = 30 Tue Nov 18 14:52:33 2003 : Debug: main: cleanup_delay = 5 Tue Nov 18 14:52:33 2003 : Debug: main: max_requests = 1024 Tue Nov 18 14:52:33 2003 : Debug: main: delete_blocked_requests = 0 Tue Nov 18 14:52:33 2003 : Debug: main: port = 0 Tue Nov 18 14:52:33 2003 : Debug: main: allow_core_dumps = no Tue Nov 18 14:52:33 2003 : Debug: main: log_stripped_names = no Tue Nov 18 14:52:33 2003 : Debug: main: log_file = "/var/log/radius/radius.log" Tue Nov 18 14:52:33 2003 : Debug: main: log_auth = yes Tue Nov 18 14:52:33 2003 : Debug: main: log_auth_badpass = yes Tue Nov 18 14:52:33 2003 : Debug: main: log_auth_goodpass = no Tue Nov 18 14:52:33 2003 : Debug: main: pidfile = "/usr/local/var/run/radiusd/radiusd.pid" Tue Nov 18 14:52:33 2003 : Debug: main: user = "(null)" Tue Nov 18 14:52:33 2003 : Debug: main: group = "(null)" Tue Nov 18 14:52:33 2003 : Debug: main: usercollide = yes Tue Nov 18 14:52:33 2003 : Debug: main: lower_user = "before" Tue Nov 18 14:52:33 2003 : Debug: main: lower_pass = "no" Tue Nov 18 14:52:33 2003 : Debug: main: nospace_user = "no" Tue Nov 18 14:52:33 2003 : Debug: main: nospace_pass = "no" Tue Nov 18 14:52:33 2003 : Debug: main: checkrad = "/usr/local/sbin/checkrad" Tue Nov 18 14:52:33 2003 : Debug: main: proxy_requests = no Tue Nov 18 14:52:33 2003 : Debug: security: max_attributes = 200 Tue Nov 18 14:52:33 2003 : Debug: security: reject_delay = 1 Tue Nov 18 14:52:33 2003 : Debug: security: status_server = no Tue Nov 18 14:52:33 2003 : Debug: main: debug_level = 0 Tue Nov 18 14:52:33 2003 : Debug: read_config_files: reading dictionary Tue Nov 18 14:52:34 2003 : Debug: read_config_files: reading naslist Tue Nov 18 14:52:34 2003 : Info: Using deprecated naslist file. Support for this will go away soon. Tue Nov 18 14:52:34 2003 : Debug: read_config_files: reading clients Tue Nov 18 14:52:34 2003 : Debug: read_config_files: reading realms Tue Nov 18 14:52:34 2003 : Info: Using deprecated realms file. Support for this will go away soon. Tue Nov 18 14:52:34 2003 : Debug: radiusd: entering modules setup Tue Nov 18 14:52:34 2003 : Debug: Module: Library search path is /usr/local/lib Tue Nov 18 14:52:34
Re: My problem with PEAP
Umm... dumb question, but you don't have "eap" listed in the authenticate section of your radiusd.conf file twice do you? --Mike On Wed, 2003-11-19 at 12:31, Bill Reid wrote: > Hey everyone, > > I continue to have a problem using peap with > freeradius-snapshot-20031110. From what I have read about EAP, and > from my discussions with others on this list, I believe I am seeing a > problem from freeradius. > > Please correct me if I am wrong. > > According to the documentation in ./doc/rlm_eap. The client is not > responding to step 6 "Access Challenge" from the radius server. I can > see the Radius packet making it to the client. The only thing I can > find that is odd about the challenge is that there are two eap portions > of the frame. My hope is that the client is ignoring the frame because > of this. > > Since there is no response from the client(supplicant) I do not get an > EAP-Success/EAP-failure and begin to negotiate any ssl/wep stuff. So I > don't even think I am verifying the server using the installed CERT at > this point. In other words, I don't suspect I have a key/cert problem > yet :). > > I have included the frames in this email. They were captured on the > radius server side. Note there are two separate attempts from the > client to authenticate itself. I am questioning either of the Access > Challenge frames. I would love it if someone could look at these frames > and tell me if they are correct (that freeradius is creating them properly). > > Below the message Authenticator is similar to 0x00. In > the frame sent to the supplicant, the second portion EAP type 79 does > not have the authenticator, the first portion EAP type 79 does have the > Message Authenticator and is filled with a value other then > 0x0. I am guessing that is where the hash for the password > goes. > > Any help would be greatly appreciated. > > Here is the output of radiusd -Xxx > > Tue Nov 18 14:52:33 2003 : Info: Starting - reading configuration files ... > Tue Nov 18 14:52:33 2003 : Debug: reread_config: reading radiusd.conf > Tue Nov 18 14:52:33 2003 : Debug: Config: including file: > /usr/local/etc/raddb/clients.conf > Tue Nov 18 14:52:33 2003 : Debug: Config: including file: > /usr/local/etc/raddb/snmp.conf > Tue Nov 18 14:52:33 2003 : Debug: main: prefix = "/usr/local" > Tue Nov 18 14:52:33 2003 : Debug: main: localstatedir = "/usr/local/var" > Tue Nov 18 14:52:33 2003 : Debug: main: logdir = "/var/log/radius" > Tue Nov 18 14:52:33 2003 : Debug: main: libdir = "/usr/local/lib" > Tue Nov 18 14:52:33 2003 : Debug: main: radacctdir = > "/var/log/radius/radacct" > Tue Nov 18 14:52:33 2003 : Debug: main: hostname_lookups = no > Tue Nov 18 14:52:33 2003 : Debug: main: max_request_time = 30 > Tue Nov 18 14:52:33 2003 : Debug: main: cleanup_delay = 5 > Tue Nov 18 14:52:33 2003 : Debug: main: max_requests = 1024 > Tue Nov 18 14:52:33 2003 : Debug: main: delete_blocked_requests = 0 > Tue Nov 18 14:52:33 2003 : Debug: main: port = 0 > Tue Nov 18 14:52:33 2003 : Debug: main: allow_core_dumps = no > Tue Nov 18 14:52:33 2003 : Debug: main: log_stripped_names = no > Tue Nov 18 14:52:33 2003 : Debug: main: log_file = > "/var/log/radius/radius.log" > Tue Nov 18 14:52:33 2003 : Debug: main: log_auth = yes > Tue Nov 18 14:52:33 2003 : Debug: main: log_auth_badpass = yes > Tue Nov 18 14:52:33 2003 : Debug: main: log_auth_goodpass = no > Tue Nov 18 14:52:33 2003 : Debug: main: pidfile = > "/usr/local/var/run/radiusd/radiusd.pid" > Tue Nov 18 14:52:33 2003 : Debug: main: user = "(null)" > Tue Nov 18 14:52:33 2003 : Debug: main: group = "(null)" > Tue Nov 18 14:52:33 2003 : Debug: main: usercollide = yes > Tue Nov 18 14:52:33 2003 : Debug: main: lower_user = "before" > Tue Nov 18 14:52:33 2003 : Debug: main: lower_pass = "no" > Tue Nov 18 14:52:33 2003 : Debug: main: nospace_user = "no" > Tue Nov 18 14:52:33 2003 : Debug: main: nospace_pass = "no" > Tue Nov 18 14:52:33 2003 : Debug: main: checkrad = > "/usr/local/sbin/checkrad" > Tue Nov 18 14:52:33 2003 : Debug: main: proxy_requests = no > Tue Nov 18 14:52:33 2003 : Debug: security: max_attributes = 200 > Tue Nov 18 14:52:33 2003 : Debug: security: reject_delay = 1 > Tue Nov 18 14:52:33 2003 : Debug: security: status_server = no > Tue Nov 18 14:52:33 2003 : Debug: main: debug_level = 0 > Tue Nov 18 14:52:33 2003 : Debug: read_config_files: reading dictionary > Tue Nov 18 14:52:34 2003 : Debug: read_config_files: reading naslist > Tue Nov 18 14:52:34 2003 : Info: Using deprecated naslist file. Support > for this will go away soon. > Tue Nov 18 14:52:34 2003 : Debug: read_config_files: reading clients > Tue Nov 18 14:52:34 2003 : Debug: read_config_files: reading realms > Tue Nov 18 14:52:34 2003 : Info: Using deprecated realms file. Support > for this will go away soon. > Tue Nov 18 14:52:34 2003 : Debug: radiusd: entering modules setup > Tue Nov 18 14:52:3
My problem with PEAP
Hey everyone, I continue to have a problem using peap with freeradius-snapshot-20031110. From what I have read about EAP, and from my discussions with others on this list, I believe I am seeing a problem from freeradius. Please correct me if I am wrong. According to the documentation in ./doc/rlm_eap. The client is not responding to step 6 "Access Challenge" from the radius server. I can see the Radius packet making it to the client. The only thing I can find that is odd about the challenge is that there are two eap portions of the frame. My hope is that the client is ignoring the frame because of this. Since there is no response from the client(supplicant) I do not get an EAP-Success/EAP-failure and begin to negotiate any ssl/wep stuff. So I don't even think I am verifying the server using the installed CERT at this point. In other words, I don't suspect I have a key/cert problem yet :). I have included the frames in this email. They were captured on the radius server side. Note there are two separate attempts from the client to authenticate itself. I am questioning either of the Access Challenge frames. I would love it if someone could look at these frames and tell me if they are correct (that freeradius is creating them properly). Below the message Authenticator is similar to 0x00. In the frame sent to the supplicant, the second portion EAP type 79 does not have the authenticator, the first portion EAP type 79 does have the Message Authenticator and is filled with a value other then 0x0. I am guessing that is where the hash for the password goes. Any help would be greatly appreciated. Here is the output of radiusd -Xxx Tue Nov 18 14:52:33 2003 : Info: Starting - reading configuration files ... Tue Nov 18 14:52:33 2003 : Debug: reread_config: reading radiusd.conf Tue Nov 18 14:52:33 2003 : Debug: Config: including file: /usr/local/etc/raddb/clients.conf Tue Nov 18 14:52:33 2003 : Debug: Config: including file: /usr/local/etc/raddb/snmp.conf Tue Nov 18 14:52:33 2003 : Debug: main: prefix = "/usr/local" Tue Nov 18 14:52:33 2003 : Debug: main: localstatedir = "/usr/local/var" Tue Nov 18 14:52:33 2003 : Debug: main: logdir = "/var/log/radius" Tue Nov 18 14:52:33 2003 : Debug: main: libdir = "/usr/local/lib" Tue Nov 18 14:52:33 2003 : Debug: main: radacctdir = "/var/log/radius/radacct" Tue Nov 18 14:52:33 2003 : Debug: main: hostname_lookups = no Tue Nov 18 14:52:33 2003 : Debug: main: max_request_time = 30 Tue Nov 18 14:52:33 2003 : Debug: main: cleanup_delay = 5 Tue Nov 18 14:52:33 2003 : Debug: main: max_requests = 1024 Tue Nov 18 14:52:33 2003 : Debug: main: delete_blocked_requests = 0 Tue Nov 18 14:52:33 2003 : Debug: main: port = 0 Tue Nov 18 14:52:33 2003 : Debug: main: allow_core_dumps = no Tue Nov 18 14:52:33 2003 : Debug: main: log_stripped_names = no Tue Nov 18 14:52:33 2003 : Debug: main: log_file = "/var/log/radius/radius.log" Tue Nov 18 14:52:33 2003 : Debug: main: log_auth = yes Tue Nov 18 14:52:33 2003 : Debug: main: log_auth_badpass = yes Tue Nov 18 14:52:33 2003 : Debug: main: log_auth_goodpass = no Tue Nov 18 14:52:33 2003 : Debug: main: pidfile = "/usr/local/var/run/radiusd/radiusd.pid" Tue Nov 18 14:52:33 2003 : Debug: main: user = "(null)" Tue Nov 18 14:52:33 2003 : Debug: main: group = "(null)" Tue Nov 18 14:52:33 2003 : Debug: main: usercollide = yes Tue Nov 18 14:52:33 2003 : Debug: main: lower_user = "before" Tue Nov 18 14:52:33 2003 : Debug: main: lower_pass = "no" Tue Nov 18 14:52:33 2003 : Debug: main: nospace_user = "no" Tue Nov 18 14:52:33 2003 : Debug: main: nospace_pass = "no" Tue Nov 18 14:52:33 2003 : Debug: main: checkrad = "/usr/local/sbin/checkrad" Tue Nov 18 14:52:33 2003 : Debug: main: proxy_requests = no Tue Nov 18 14:52:33 2003 : Debug: security: max_attributes = 200 Tue Nov 18 14:52:33 2003 : Debug: security: reject_delay = 1 Tue Nov 18 14:52:33 2003 : Debug: security: status_server = no Tue Nov 18 14:52:33 2003 : Debug: main: debug_level = 0 Tue Nov 18 14:52:33 2003 : Debug: read_config_files: reading dictionary Tue Nov 18 14:52:34 2003 : Debug: read_config_files: reading naslist Tue Nov 18 14:52:34 2003 : Info: Using deprecated naslist file. Support for this will go away soon. Tue Nov 18 14:52:34 2003 : Debug: read_config_files: reading clients Tue Nov 18 14:52:34 2003 : Debug: read_config_files: reading realms Tue Nov 18 14:52:34 2003 : Info: Using deprecated realms file. Support for this will go away soon. Tue Nov 18 14:52:34 2003 : Debug: radiusd: entering modules setup Tue Nov 18 14:52:34 2003 : Debug: Module: Library search path is /usr/local/lib Tue Nov 18 14:52:34 2003 : Debug: Module: Loaded expr Tue Nov 18 14:52:34 2003 : Debug: Module: Instantiated expr (expr) Tue Nov 18 14:52:34 2003 : Debug: Module: Loaded eap Tue Nov 18 14:52:34 2003 : Debug: eap: default_eap_type = "peap" Tue Nov 18 14:52:34 2003 : Debug: eap: timer_expire =