> I tried upgrading to 2.4.20, and it still happens...randomly, it seems
> (it happened about every 20 minutes up until noon yesterday, and hasn't
> yet today), though I noticed another symptom...apparently some accounting
> entries are getting corrupted (replaced with garbage). It hasn't
> happened yet today, but did happen yesterday, so I think they may be
> connected.
I am attempting to upgrade to 2.4.20. The radiusd will not even start.
Running it in standalone mode, not from inetd (at the moment). Our specs:
Merit 2.4.20, BSDI 2.0/486, No shadow.h. No other patches or modifications
except the one below.
I had to make a change in las.token.c to make it compile:
[6] vangogh.wic.net:/ockers/work/radius-2.4.20/src > diff las.token.c las.token.c.orig
712c712
< fwrite (&buf, 1, ptr - (char *) &buf, fp);
--- > fwrite (buf, 1, ptr - (char *) &buf, fp);cc complained about incompatible arguments or some such without the ampersand in front of the first buf. I'm not a real C programmer so I may have totally screwed something up there. But at least it compiled, whereas it didn't before I made that change. (It should be noted that RADIUS compiled without the LAS stuff, but with the LAS stuff that change was necessary.)
The compiled radiusd+LAS will not even start; it says "segmentation fault" and dies. An inspection of the radius.debug file (generated by -x -x -x -x) tells me nothing. The last few lines are:
rad_ipc_init: entered rad_2rad_init: entered find_auth_type: entered find_file_ent: entered find_auth_type: realm not found find_auth_type: entered find_file_ent: entered find_auth_type: type 1, agent '', realm 'NULL' and filter ''
We don't use realms (yet). There are no other apparent problems that turn up in the debug file. The debug file ends each time right after that find_auth_type: line.
Running a ktrace (BSDI syscall trace) on radiusd tells the following (here are the last few lines):
1095 radiusd GIO fd 9 read 0 bytes "" 1095 radiusd RET read 0 1095 radiusd CALL stat(0xefbfd610,0xefbfda10) 1095 radiusd NAMI "/usr/private/etc/raddb/session.las" 1095 radiusd RET stat -1 errno 2 No such file or directory 1095 radiusd CALL gettimeofday(0xefbfd644,0) 1095 radiusd RET gettimeofday 0 1095 radiusd PSIG SIGSEGV SIG_DFL 1095 radiusd NAMI "radiusd.core"
The SIGSEGV always seems to happen right after the gettimeofday(). Is that returned value of 0 the Big Problem?
> Again, running Merit 2.4.20, Linux/i586, PD shadow passwords, running > from inetd. Similar experiences? Clues?
P.S.
WEB if you are reading this, there is a problem with the lasrecord perl script in the 2.4.20 LAS archive. It needs an ampersand before the subroutine name in order to call a subroutine in this spot (here is a diff):
--- lasrecord.orig Fri Feb 23 06:38:52 1996 +++ lasrecord Fri Feb 23 06:37:00 1996 @@ -118,6 +118,6 @@ $uniqname =~ tr/[\040-\176]//cd; defined (@users) && (grep (/^$uniqname$/i, @users) || next);
- $stop = print_LAS_record (@rec); + $stop = &print_LAS_record (@rec); } }
Thanks in advance for any advice, hints or suggestions! Sorry I'm not more help to the original poster.
-- Jim (ockers@davidalan.com) Ask me about Linux!My own site! Check out http://ducktape.davidalan.com/