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
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
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_path = (null)
tls: pem_file_type = yes
tls:
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Ñ?B 000dbda1f1e9 000dbd05196d 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
detailperm = 0600
}
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
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
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
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 = 60 Tue Nov 18 14:52:34 2003 :
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:34 2003 : Debug: Module: Library search path is /usr/local/lib Tue Nov 18 14:52:34 2003 : Debug: Module: Loaded expr
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 2003 : Debug: Module: Loaded
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
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
