radclient: problem with exit code 0 and 1
Hello, for monitoring our radius-servers, I use radclient for a long time in a script. After migration to another platform, radclient seems to work else, than before. If a monitored radiusd is down or the Auth of my monitoring-user fails, radclient gets an expected answer, but exits with status 0 in these cases. As far as I remember, in the past it was exit 1 (--> echo $?=1). I used to process exit 1 to indicate a problem with my radius-servers. Has this behaviour changed somewhere in the past? Or is it the wanted behaviour, that every valid answer to radclient exits with status 0 now? Take this for example: # /usr/bin/radclient -f /home/me/radpacket -x 192.168.x.x:1812 auth secret123 Sending Access-Request of id 248 to 192.168.x.x port 1812 User-Name = "test-user" Password = "XXXXXXX" NAS-IP-Address = 255.255.255.255 NAS-Port = 10 radclient: no response from server for ID 248 # echo $? 0 ... I expected $? to be 1, because the server was down and did not respond, what indicates an error. I am running radclient from freeradius 1.1.3-3, Debian/etch amd64: # radclient -v radclient: $Id: radclient.c,v 1.72.2.1.2.5 2006/05/16 18:26:08 aland Exp $ built on Dec 17 2006 at 01:07:36 Any ideas? thnx
Hello everyone, I'm another newbie here trying to figure out a problem with the Apple- fied version of FR that ships with MacOS X 10.5 Leopard Server. according to -v its v 1.1.4 with security changes through 1.1.7 For the most part it works fine. Our clients are authenticated without any problems, but fairly frequently i'm getting segmentation faults and it quits. Apple support has been no help (not surprising). Also, i've been running FR in debug mode and noticed that I can start it with radiusd -X but using -x or -xx doesn't work. I'm quite new to Radius and may be overlooking something obvious. Any help would be appreciated. Thanks. -Randy
I'm thinking it would probably help if I included some of the output. This is from right before the crash. Thanks again for any help. -Randy Waking up in 4 seconds... rad_recv: Access-Request packet from host 128.6.30.217:32771, id=162, length=144 User-Name = "ayako" NAS-IP-Address = 128.6.30.217 NAS-Port = 2051 Called-Station-Id = "00-90-0B-09-B5-24:Waksman" Calling-Station-Id = "00-11-24-A9-D0-9E" Framed-MTU = 1250 NAS-Port-Type = Wireless-802.11 Connect-Info = "CONNECT 802.11g" EAP-Message = 0x0201000a016179616b6f Message-Authenticator = 0x6a66a1fb7a4c01dd9571942d24335e26 Processing the authorize section of radiusd.conf modcall: entering group authorize for request 111 modcall[authorize]: module "preprocess" returns ok for request 111 modcall[authorize]: module "chap" returns noop for request 111 modcall[authorize]: module "mschap" returns noop for request 111 rlm_realm: No '@' in User-Name = "ayako", looking up realm NULL rlm_realm: No such realm "NULL" modcall[authorize]: module "suffix" returns noop for request 111 rlm_eap: EAP packet type response id 1 length 10 rlm_eap: No EAP Start, assuming it's an on-going EAP conversation modcall[authorize]: module "eap" returns updated for request 111 users: Matched entry DEFAULT at line 153 modcall[authorize]: module "files" returns ok for request 111 rlm_opendirectory: The SACL group "com.apple.access_radius" does not exist on this system. rlm_opendirectory: The host 128.6.30.217 does not have an access group. rlm_opendirectory: no access control groups, all users allowed. modcall[authorize]: module "opendirectory" returns ok for request 111 modcall: leaving group authorize (returns updated) for request 111 rad_check_password: Found Auth-Type EAP auth: type "EAP" Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 111 rlm_eap: EAP Identity rlm_eap: processing type tls rlm_eap_tls: Initiate rlm_eap_tls: Start returned 1 modcall[authenticate]: module "eap" returns handled for request 111 modcall: leaving group authenticate (returns handled) for request 111 Sending Access-Challenge of id 162 to 128.6.30.217 port 32771 EAP-Message = 0x010200061520 Message-Authenticator = 0x00000000000000000000000000000000 State = 0x15a7beab1366439e1fad3ea73f345a2b Segmentation fault On Mar 18, 2009, at 11:51 AM, Randall Newman wrote:
Hello everyone,
I'm another newbie here trying to figure out a problem with the Apple-fied version of FR that ships with MacOS X 10.5 Leopard Server. according to -v its v 1.1.4 with security changes through 1.1.7
For the most part it works fine. Our clients are authenticated without any problems, but fairly frequently i'm getting segmentation faults and it quits. Apple support has been no help (not surprising). Also, i've been running FR in debug mode and noticed that I can start it with radiusd -X but using -x or -xx doesn't work. I'm quite new to Radius and may be overlooking something obvious. Any help would be appreciated. Thanks.
-Randy
Randall Newman wrote:
For the most part it works fine. Our clients are authenticated without any problems, but fairly frequently i'm getting segmentation faults and it quits. Apple support has been no help (not surprising). Also, i've been running FR in debug mode and noticed that I can start it with radiusd -X but using -x or -xx doesn't work. I'm quite new to Radius and may be overlooking something obvious. Any help would be appreciated.
Check the file permissions on the configuration directories. The command-line option "-X" means "run as whoever started the server", usually root. "-x" means "print more debugging output", but it can still change uid's. See radiusd.conf for details. You may also try upgrading to a recent version of the server. It works on Mac OS X, among many other platforms. Alan DeKok.
I looked at the permissions but everything looks ok, so still not sure why the -x and -xx options are not working, but that's not my main problem. I did notice one strange thing in the log shortly before one of the segmentation faults. Not sure if its related but perhaps someone here can shed some light: radiusd(32122,0xa0479720) malloc: *** error for object 0x1d3610: incorrect checksum for freed object - object was probably modified after being freed. *** set a breakpoint in malloc_error_break to debug Thanks. -Randy On Mar 18, 2009, at 1:21 PM, Alan DeKok wrote:
Randall Newman wrote:
For the most part it works fine. Our clients are authenticated without any problems, but fairly frequently i'm getting segmentation faults and it quits. Apple support has been no help (not surprising). Also, i've been running FR in debug mode and noticed that I can start it with radiusd -X but using -x or -xx doesn't work. I'm quite new to Radius and may be overlooking something obvious. Any help would be appreciated.
Check the file permissions on the configuration directories. The command-line option "-X" means "run as whoever started the server", usually root.
"-x" means "print more debugging output", but it can still change uid's. See radiusd.conf for details.
You may also try upgrading to a recent version of the server. It works on Mac OS X, among many other platforms.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Randall Newman wrote:
I looked at the permissions but everything looks ok, so still not sure why the -x and -xx options are not working, but that's not my main problem. I did notice one strange thing in the log shortly before one of the segmentation faults. Not sure if its related but perhaps someone here can shed some light:
radiusd(32122,0xa0479720) malloc: *** error for object 0x1d3610: incorrect checksum for freed object - object was probably modified after being freed. *** set a breakpoint in malloc_error_break to debug
Yes, that would be related. It's a bug. The simple suggestion is to upgrade to a recent version, which won't have this bug. Alan DeKok.
oz wrote:
for monitoring our radius-servers, I use radclient for a long time in a script. After migration to another platform, radclient seems to work else, than before. If a monitored radiusd is down or the Auth of my monitoring-user fails, radclient gets an expected answer, but exits with status 0 in these cases.
Hmm... good point. I'll take a look at that.
I am running radclient from freeradius 1.1.3-3, Debian/etch amd64: # radclient -v radclient: $Id: radclient.c,v 1.72.2.1.2.5 2006/05/16 18:26:08 aland Exp $ built on Dec 17 2006 at 01:07:36
Err... that won't be fixed. The fix will be in a recent version of the server. Not one that is three years old. Alan DeKok.
Hello, Alan DeKok wrote:
oz wrote:
for monitoring our radius-servers, I use radclient for a long time in a script. After migration to another platform, radclient seems to work else, than before. If a monitored radiusd is down or the Auth of my monitoring-user fails, radclient gets an expected answer, but exits with status 0 in these cases.
Hmm... good point. I'll take a look at that.
the normal behavior of radclient seems to get lost somewhere in the versions later than freeradius-0.7, where it worked: ... radclient: no response from server host1:/usr/local/src/freeradius-0.7/src/main# echo $? 1 ... with ./radclient -v radclient: $Id: radclient.c,v 1.46 2002/06/21 19:57:26 cparker Exp $ built on Nov 5 2002 at 09:31:53 And it fails with later versions like # radclient -v radclient: $Id: radclient.c,v 1.72.2.1.2.7 2007/04/07 22:22:51 aland Exp $ built on No v 16 2007 at 14:04:12 ... from freeradius-1.1.7 and ... radclient -v radclient: $Id: radclient.c,v 1.120 2008/04/03 13:43:12 aland Exp $ built on Jul 7 20 08 at 16:01:22 ... from freeradius-2.0.5: radclient -v radclient: $Id: radclient.c,v 1.120 2008/04/03 13:43:12 aland Exp $ built on Jul 7 20 08 at 16:01:22 Kind regards, oz
I am running radclient from freeradius 1.1.3-3, Debian/etch amd64: # radclient -v radclient: $Id: radclient.c,v 1.72.2.1.2.5 2006/05/16 18:26:08 aland Exp $ built on Dec 17 2006 at 01:07:36
Err... that won't be fixed.
The fix will be in a recent version of the server. Not one that is three years old.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
oz wrote:
the normal behavior of radclient seems to get lost somewhere in the versions later than freeradius-0.7, where it worked:
That's nice... but 1.1.x will NOT be fixed. I've committed a fix that will be in the next release of the server. If you need this functionality, upgrade. Alan DeKok.
Alan DeKok wrote:
oz wrote:
the normal behavior of radclient seems to get lost somewhere in the versions later than freeradius-0.7, where it worked:
That's nice... but 1.1.x will NOT be fixed.
I've committed a fix that will be in the next release of the server. If you need this functionality, upgrade.
Thanks, but for some reasons I cannot do updates to the upcoming release on that server. So I compiled 0.7 this morning, just to get the radclient tool from that release. It was succesfully built, yeay, but has another bug with masking the password when it is used in the radtest-script :-/ Sending Access-Request of id 110 to 192.168.X.X:1812 User-Name = "testuser" User-Password = "\360\213[p\224\212I\314\217\343\361\214\370\326\351$" Do you have an idea, which freeradius version after 0.7 has a working exit code 1, but is free from that other problem with the password-masking? Then I'd like to try that. Else I would have to test-compile the 19 releases between 0.7 and 1.1.7 for a possible workaround. oz
from that release. It was succesfully built, yeay, but has another bug with masking the password when it is used in the radtest-script :-/
Sending Access-Request of id 110 to 192.168.X.X:1812 User-Name = "testuser" User-Password = "\360\213[p\224\212I\314\217\343\361\214\370\326\351$"
Not a bug. Shared secret is wrong. Ivan Kalik Kalik Informatika ISP
tnt@kalik.net wrote:
from that release. It was succesfully built, yeay, but has another bug with masking the password when it is used in the radtest-script :-/
Sending Access-Request of id 110 to 192.168.X.X:1812 User-Name = "testuser" User-Password = "\360\213[p\224\212I\314\217\343\361\214\370\326\351$"
Not a bug. Shared secret is wrong.
It looks like a wrong shared secret, ... usr/local/src/freeradius-0.9.2/src/main# ./radclient -d /usr/local/src/freeradius-0.9.2/share -f /home/me/radpacket -x 192.168.111.18:1812 auth test123 Sending Access-Request of id 20 to 192.168.111.18:1812 User-Name = "testuser" Password = "testpassword" NAS-IP-Address = pluto NAS-Port = 10 rad_recv: Access-Reject packet from host 192.168.111.18:1812, id=20, length=20 rad_decode: Received Access-Reject packet from 192.168.111.18 with invalid signature (err=2)! (Shared secret is incorrect.) ... but it is not wrong, I used the same secret as on 2.1.4, where it works. I compiled both versions on an AMD64 arch and found some hints on the internet, that this might be the problem. Version 0.9.2 is from October 2003, so it is probably too old. As Alan said, I have to wait for a new release of freeradius. Thanks for your help, oz
oz wrote:
Thanks, but for some reasons I cannot do updates to the upcoming release on that server.
Uh... you *can* run just radclient from the new version of the server. You don't have to upgrade the server to run radclient. Just make sure that the new version is installed in an independent directory, and isn't in the PATH.
So I compiled 0.7 this morning, just to get the radclient tool from that release. It was succesfully built, yeay, but has another bug with masking the password when it is used in the radtest-script :-/
Stop wasting your time with old versions of the server. We can't help you fix, or understand, code that is many years old. It's not worth *our* time to re-debug problems that were found and fixed years ago. Alan DeKok.
Alan DeKok wrote:
Uh... you *can* run just radclient from the new version of the server. You don't have to upgrade the server to run radclient.
Yes, thanks, I built the latest 2.1.4 but it still has the bug: /usr/local/src/freeradius-server-2.1.4/src/main# ./radclient -d /usr/local/src/freeradius-server-2.1.4/share -f /home/me/radpacket -x 192.168.X.X:1812 auth secret123 Sending Access-Request of id 41 to 192.168.X.X port 1812 User-Name = "testuser" Password = "testpassword" NAS-IP-Address = 192.168.x.x NAS-Port = 10 ... radclient: no response from server for ID 41 socket 3 yoda:/usr/local/src/freeradius-server-2.1.4/src/main# echo $? 0 I just hope to find a workaround for my alarm-monitoring in using an old version, until a fixed version of freeradius is released. - Ok, now that I know, you will fix it, I can wait. Thanks for your help, oz
Hello, Alan DeKok wrote:
I've committed a fix that will be in the next release of the server. If you need this functionality, upgrade.
I tried your git repository as described on freeradius.org. I do not understand the versioning scheme, but I downloaded the fixed stable tree (upcoming 2.1.5?) and built it without 'make install' on my AMD64-Machine. The problem in radclient is fixed, thank you Alan! I just had to append the new dictionary path in my scripts, because the dictionaries of my old inst do not work with the new radclient: ./radclient -d /usr/local/src/radiusd/share -f /home/me/radpacket -x 192.168.X.X:1812 auth secret123 Thanks for your fast help! oz
participants (4)
-
Alan DeKok -
oz -
Randall Newman -
tnt＠kalik.net