Querry on localhost testing
Hi I have intalled free-radius-0.9.0 on LINUX .. I doing local host testing ... using radtest ..I am geting access reject instead of access accept these are details Client side [EMAIL PROTECTED] raddb]# radtest rudra rudra localhost 10 testing123 Sending Access-Request of id 192 to 127.0.0.1:1812 User-Name = rudra User-Password = rudra NAS-IP-Address = localhost.localdomain NAS-Port = 10 rad_recv: Access-Reject packet from host 127.0.0.1:1812, id=192, length=20 Server Side 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 Can any body help to solve this problem - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Querry on localhost testing
I am using first time Free RADIUS i don't details.. can u tell me in details - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Querry on localhost testing
Tom Emerson [EMAIL PROTECTED] wrote: Alan, to you it is insanely obvious, to a first timer reading hundreds of lines of potentially useful output, the critical bits are buried in the noise It's only a few hundred lines of text, most of which are simple to understand. It should take less time to read that text than to send a message to the list, and wait for a response. would it have really taken that long for you to say: That is exactly, 100%, my point. Would it have taken HIM that long to READ the debug log? No. So he was too lazy to read the messages, and I was too lazy to cut paste the relevant portions for him to digest. But you're upset at my behaviour, and not at his. Nice. Things to check: [ok alan, this is where it gets subjective, and I'm sure for you overly repetitive -- NOW you can refer someone to a FAQ (if it's in there) and specifically WHERE in the FAQ to start looking] The debug information contains sufficient information for someone to solve most problems, IF and ONLY IF they read it. Adding more documentation, FAQ entries, and answering questions on email lists will NOT help the people who too lazy to do anything themselves. What they want is for someone else to do the hard thinking for them. The way to correct that attitude is NOT through more documentation: they don't care, and won't read it. The way to correct it is to tell them to do some work themselves. Not the exact answer, but some directions for someone new to this to start looking... Type up a step-by-step howto guide for debugging problems like this, and I'll include it in the server documentation. But don't expect it to answer many of these questions... the people who need it the most won't bother to read it. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Querry on localhost testing
Rudramuni PH [EMAIL PROTECTED] wrote: Full Debug in formation ... sigh Go back and read it. The answer to your question is in the debug log you posted to the list. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Querry on localhost testing
In his inimicable (?) style, Alan DeKok wrote: Rudramuni PH [EMAIL PROTECTED] wrote: Full Debug in formation ... sigh Go back and read it. The answer to your question is in the debug log you posted to the list. Alan, to you it is insanely obvious, to a first timer reading hundreds of lines of potentially useful output, the critical bits are buried in the noise -- would it have really taken that long for you to say: Full Debug in formation [...] rad_recv: Access-Request packet from host 127.0.0.1:1025, id=152, length=57 [...] User-Name = rudra User-Password = rudra NAS-IP-Address = 255.255.255.255 NAS-Port = 10 This [hopefully obvious] section shows you what the server parsed out of the request users: Matched DEFAULT at 152 This important line tells you what the server believes to be the user to be validated [...] rad_check_password: Found Auth-Type System this important line tells us that we'll be looking up the user in the /etc/passwd file, i.e., we expect the user to be a regular user of the linux server itself modcall[authenticate]: module unix returns notfound modcall: group authenticate returns notfound auth: Failed to validate the user. and as you might imagine, we don't find a user called rudra in the system. Things to check: [ok alan, this is where it gets subjective, and I'm sure for you overly repetitive -- NOW you can refer someone to a FAQ (if it's in there) and specifically WHERE in the FAQ to start looking] -- the conf file to figure out why the wrong authentication method was being used [i.e., system] -- the user's file to figure out why the user rudra wasn't found/matched -- any databases in use? properly configured? right op values? Not the exact answer, but some directions for someone new to this to start looking... -- Yet another Blog: http://osnut.homelinux.net pgp0.pgp Description: signature
Re: Querry on localhost testing
Thanks Alan I got the answer what ever u r saying also correct... i have study more on the code . regards rudra Alan DeKok [EMAIL PROTECTED] Sent by:To: [EMAIL PROTECTED] [EMAIL PROTECTED]cc: .cistron.nl Subject: Re: Querry on localhost testing 08/08/2003 08:43 PM Please respond to freeradius-users Tom Emerson [EMAIL PROTECTED] wrote: Alan, to you it is insanely obvious, to a first timer reading hundreds of lines of potentially useful output, the critical bits are buried in the noise It's only a few hundred lines of text, most of which are simple to understand. It should take less time to read that text than to send a message to the list, and wait for a response. would it have really taken that long for you to say: That is exactly, 100%, my point. Would it have taken HIM that long to READ the debug log? No. So he was too lazy to read the messages, and I was too lazy to cut paste the relevant portions for him to digest. But you're upset at my behaviour, and not at his. Nice. Things to check: [ok alan, this is where it gets subjective, and I'm sure for you overly repetitive -- NOW you can refer someone to a FAQ (if it's in there) and specifically WHERE in the FAQ to start looking] The debug information contains sufficient information for someone to solve most problems, IF and ONLY IF they read it. Adding more documentation, FAQ entries, and answering questions on email lists will NOT help the people who too lazy to do anything themselves. What they want is for someone else to do the hard thinking for them. The way to correct that attitude is NOT through more documentation: they don't care, and won't read it. The way to correct it is to tell them to do some work themselves. Not the exact answer, but some directions for someone new to this to start looking... Type up a step-by-step howto guide for debugging problems like this, and I'll include it in the server documentation. But don't expect it to answer many of these questions... the people who need it the most won't bother to read it. 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: Querry on localhost testing
Rudramuni PH [EMAIL PROTECTED] wrote: I doing local host testing ... using radtest ..I am geting access reject instead of access accept ... Server Side Starting - reading configuration files ... ... unix: cache_reload = 600 And you've carefully cut out the most important piece of the debug log: where it receives the packet anbd processes it. Can any body help to solve this problem Read the rest of the debug log, which you didn't post to the list. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Querry on localhost testing
Full Debug in formation
I have runnin lik the on server side
radiusd -xxyz -l stdout
Ouput is below
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 = md5
eap: timer_expire = 60
rlm_eap: Loaded and initialized the type md5
rlm_eap: Loaded and initialized the type leap
Module: Instantiated eap (eap)
Module: Loaded preprocess
preprocess: huntgroups = /usr/local/etc/raddb/huntgroups
preprocess: hints = /usr/local/etc/raddb/hints
preprocess: with_ascend_hack = no
preprocess: ascend_channels_per_line = 23
preprocess: with_ntdomain_hack = no
preprocess: with_specialix_jetstream_hack = no
preprocess: with_cisco_vsa_hack = no
Module: Instantiated preprocess (preprocess)
Module: Loaded realm
realm: format = suffix
realm: delimiter = @
Module: Instantiated realm (suffix)
Module: Loaded files
files: usersfile = /usr/local/etc/raddb/users
files: acctusersfile = /usr/local/etc/raddb/acct_users
files: preproxy_usersfile = /usr/local/etc/raddb/preproxy_users
files: compat = no
Module: Instantiated files (files)
Module: Loaded Acct-Unique-Session-Id
acct_unique: key = User-Name, Acct-Session-Id, NAS-IP-Address,
Client-IP-Address, NAS-Port-Id
Module: Instantiated acct_unique (acct_unique)
Module: Loaded detail
detail: detailfile
= /usr/local/var/log/radius/radacct/%{Client-IP-Address}/detail-%Y%m%d
detail: detailperm = 384
detail: dirperm = 493
detail: locking = no
Module: Instantiated detail (detail)
Module: Loaded radutmp
radutmp: filename = /usr/local/var/log/radius/radutmp
radutmp: username = %{User-Name}
radutmp: case_sensitive = yes
radutmp: check_with_nas = yes
radutmp: perm = 384
radutmp: callerid = yes
Module: Instantiated radutmp (radutmp)
Initializing the thread pool...
thread: start_servers = 5
thread: max_servers = 32
thread: min_spare_servers = 3
thread: max_spare_servers = 10
thread: max_requests_per_server = 0
thread: cleanup_delay = 5
Thread 1 waiting to be assigned a request
Thread spawned new child 1. Total threads in pool: 1
Thread spawned new child 2. Total threads in pool: 2
Thread 3 waiting to be assigned a request
Thread 2 waiting to be assigned a request
Thread spawned new child 3. Total threads in pool: 3
Thread 4 waiting to be assigned a request
Thread spawned new child 4. Total threads in pool: 4
Thread spawned new child 5. Total threads in pool: 5
Listening on IP address *, ports 1812/udp and 1813/udp, with proxy on
1814/udp.
Ready to process requests.
Thread 5 waiting to be assigned a request
