_______________________________________________________________
/ /
/ Gary Swofford - Hampton Roads Online - Yorktown Virginia USA /
/ http://www.hroads.net /
/_______________________ gary@hroads.net_______________________/
---------- Forwarded message ----------
>From john@mail.redshift.com Tue Apr 29 14:28:50 1997
Date: Tue, 29 Apr 1997 10:26:26 -0700 (PDT)
From: john@mail.redshift.com
To: gary@hroads.net
Subject: Re: Radius 2.0 and Linux 2.0.30
Gary...
here's what i did to compile a clean version of 2.0. i had the same
problem.
the errors are because of SECURID.
1. go to the radius/src dir and edit Makefile. remove the lines mentioned
in the comments: -DSECURID, and remove the entries for the LIBS and XOBJS.
2. then edit the make.inc file in the same dir. this is where your
compile is breaking. you removed the securid stuff from Makefile, but
this also has references to it. get rid of the sd stuff so that your
HEADERS entry only has this:
HEADERS = $(SRC_DIR)/conf.h $(SRC_DIR)/md5.h $(SRC_DIR)/radius.h \
$(SRC_DIR)/users.h
that's all you need.
3. go to the Linux dir as before and run make.
it will compile. however, there is a teeny bug, apparently, that will
cause a SIG100 and radius will die. i've found , from others, that
editing a small part of the radiusd.c file (see below, for email on
subject) will prevent that. it may or may not stablize rad2.0 and
may not fix or address other issues. i am running it this way,and
it seems ok.
***
more included email:
Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id SAA29252 for portmaster-users-outgoing; Fri, 4 Apr 1997 18:07:00 -0800 (PST)
Date: Fri, 4 Apr 1997 18:06:58 -0800 (PST)
From: Carl Rigney <cdr@livingston.com>
Message-Id: <199704050206.SAA29243@server.livingston.com>
To: megazone@livingston.com
Subject: Re: RADIUS bug... (fwd)
Cc: chad@txdirect.net, portmaster-users@livingston.com
Sender: owner-portmaster-users@livingston.com
Precedence: bulk
Reply-To: Carl Rigney <cdr@livingston.com>
Status: RO
Yes, that is indeed the fix, and it'll be in RADIUS 2.0.1 when that
comes out (soon now). In the meantime, people can just make the fix
Mr. Scott suggests and that will work fine.
Once upon a time Chad Scott shaped the electrons to say...
>From owner-portmaster-users Fri Apr 4 13:40:47 1997
Date: Fri, 4 Apr 1997 15:41:30 -0600 (CST)
From: Chad Scott <chad@txdirect.net>
To: portmaster-users@livingston.com
Subject: RADIUS bug...
Message-ID: <Pine.BSI.3.94.970404152931.15093A-100000@legend.txdirect.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-portmaster-users
Precedence: bulk
Reply-To: Chad Scott <chad@txdirect.net>
I've been having a bad problem with radiusd 2.0 crashing when any of my
Ascend products reboot, and I believe I have found the problem.
Ascend MAXen send out a packet via RADIUS whenever they restart. This
packet has a different request code and is handled properly in Ascend's
version of radiusd. Livingston's new 2.0 radiusd doesn't handle this new
request code properly and dumps core.
After putting symbols into my radiusd and profiling for weeks, I believe I
have found the cause. It amounts to a typo in radiusd.c.
At lines 717-718 in radiusd.c there is the following subroutine call:
log_err("unknown request type %d from %s ignored\n",
ip_hostname(authreq->ipaddr), authreq->code);
The problem seems to be that ip_hostname(...) returns a pointer to a
string and authreq->code is a char holding a value. I think whomever
programmed this particular part of radiusd simply confused the two.
Changing line 717-718 to the following seems to correct the problem:
log_err("unknown request type %d from %s ignored\n",
authreq->code, ip_hostname(authreq->ipaddr));
I'm testing the changed code with my Ascend MAXen and I haven't seen any
problems yet (knock on wood).
Anyone care to comment?