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?
Chad Scott | chad@txdirect.net
Systems Administrator | Voice 210-308-9800 x206
Internet Direct, Incorporated | FAX 210-308-9240
---------------------------------------------------------
Finger chad@txdirect.net for PGP Public Key