This has been reported repeatedly and found and fixed and will appear
in the next release.
> 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 ''
Send me a copy of your (modified) authfile and look in the logfile too
(not just the radius.debug file).
> 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?
The problem is a couple of close(2) calls in the LAS code which need to be
turned into fclose(3) calls -- I don't have the exact lines numbers right
in front of me, just look for the calls to close(2) in *las*.c and make
sure they are the ones which follow a call to fopen(3) somewhere above...
> 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 for the Perl tip! (How come it worked for me?)
Regards,
web...
-- William Bulley, N8NXN Senior Systems Research Programmer Merit Network Inc. Domain: web@merit.edu 4251 Plymouth Road MaBell: (313) 764-9993 Ann Arbor, Michigan 48105-2785 Fax: (313) 747-3185