(RADIATOR) Possible bug in Radiator's AuthDYNADDRESS.pm
Leon Oosterwijk
leon at isdn.net
Thu May 30 13:31:15 CDT 2002
Hugh,Mike,
We switched to using the Radiator's Address Allocator routines. I recently
discovered what I perceive to be a bug in the mapResult function. I noticed
that our NAS was getting sporadic occurances of users getting an address
assigned from our backup pool. This pool is only on the NAS in case the
Address Allocation Radiator provides fails. When doing research I noticed
that Radiator does not properly strip out existing Framed-Ip-Address
attributes when adding it's allocated address to a packet. Concider the
following:
Radiator 3.0
User: leonppp
Reply Items:
Service-Type Framed-User
Framed-Protocol PPP
Framed-IP-Address 255.255.255.254
Framed-IP-Netmask 255.255.255.255
Framed-Compression Van-Jacobson-TCP-IP
Framed-MTU 1500
Ascend-Idle-Limit 1200
Ascend-PPP-Address 127.0.0.5
Ascend-Maximum-Channels 1
Ascend-Maximum-Call-Duration 180
Relevant portion of config:
<AuthBy GROUP>
Identifier IsdnAuth
AuthByPolicy ContinueWhileAccept
<AuthBy SQL>
# Adjust DBSource, DBUsername, DBAuth to suit your DB
DBSource dbi:secret:secret
DBUsername secret
DBAuth secret
# The SQL SELECT statement to fetch the right data from the
Mysql DB
AuthSelect select PASSWORD, CHECKATTR, REPLYATTR from
SUBSCRIBERS where USERNAME='%n'
AuthColumnDef 0, User-Password, check
AuthColumnDef 1, GENERIC, check
AuthColumnDef 2, GENERIC, reply
AddToReply Ascend-Shared-Profile-Enable =
Shared-Profile-Yes
AddToReplyIfNotExist Service-Type = Framed, Framed-Protocol
= PPP, Pool = 3
</AuthBy>
<AuthBy GROUP>
AuthByPolicy ContinueAlways
AuthBy IsdnAcctAuth
AuthBy DynAuth
StripFromReply Pool
</AuthBy>
</AuthBy>
RadpwTst:
[root at host raddb]# radpwtst -user leonppp -password secret -noacct -trace
sending Access-Request...
Packet dump:
*** Sending to 127.0.0.1 port 1645 ....
Code: Access-Request
Identifier: 153
Authentic: 1234567890123456
Attributes:
User-Name = "leonppp"
Service-Type = Framed-User
NAS-IP-Address = 203.63.154.1
NAS-Port = 1234
Called-Station-Id = "123456789"
Calling-Station-Id = "987654321"
NAS-Port-Type = Async
User-Password =
"<154><227>6<206><196>9j<129><213>Vn<211><216>}x<153>"
Packet dump:
*** Received from 127.0.0.1 port 1645 ....
Code: Access-Accept
Identifier: 153
Authentic: <173>2<182><179><27><142><245>:<225>5><135><183>N<250>|
Attributes:
Framed-IP-Address = 255.255.255.254
Service-Type = Framed
Framed-Protocol = PPP
Framed-IP-Netmask = 255.255.255.255
Framed-Compression = Van-Jacobson-TCP-IP
Framed-MTU = 1500
Ascend-Idle-Limit = 1200
Ascend-PPP-Address = 127.0.0.5
Ascend-Maximum-Channels = 1
Ascend-Maximum-Call-Duration = 180
Ascend-Shared-Profile-Enable = Shared-Profile-Yes
Framed-IP-Netmask = 255.255.255.255
Framed-IP-Address = 207.65.130.40
OK
Notice that there are two Framed-IP-Address entries in this packet. Not
good. Apparently our NAS almost always picks the last one, but sometimes
(hence the sporadic use of the backup pool on our unit) the first one.
Now. If I make the following change to the AuthDYNADDRESS.pm
#####################################################################
# Take an allocation result, and map it into redius reply
# attributes
sub mapResult
{
my ($self, $result, $p) = @_;
# Now go through the list of allocation results that
# we have to map into radius reply attribtues
my $name;
foreach $name (sort keys %{$self->{MapAttribute}})
{
# If there is a definition for this result,
# and the corresponding radius reply attribute
# is not already set in the reply, and we
# actually have a value for it, then set it
my $value;
if ($self->{MapAttribute}{$name} ne ''
&& $$result{$name} ne ''
&& ! $p->get_attr($name))
{
# $p->add_attr($self->{MapAttribute}{$name}, $$result{$name});
# Changed by Leon May 2002 to use Change. Change will change existing
# Attribute, or if not exist, add a new one.
$p->change_attr($self->{MapAttribute}{$name}, $$result{$name});
}
}
}
And restart radiator:
[root at host raddb]# radpwtst -user leonppp -password secret -noacct -trace
sending Access-Request...
Packet dump:
*** Sending to 127.0.0.1 port 1645 ....
Code: Access-Request
Identifier: 163
Authentic: 1234567890123456
Attributes:
User-Name = "leonppp"
Service-Type = Framed-User
NAS-IP-Address = 203.63.154.1
NAS-Port = 1234
Called-Station-Id = "123456789"
Calling-Station-Id = "987654321"
NAS-Port-Type = Async
User-Password =
"<154><227>6<206><196>9j<129><213>Vn<211><216>}x<153>"
Packet dump:
*** Received from 127.0.0.1 port 1645 ....
Code: Access-Accept
Identifier: 163
Authentic: <188><175>D<214><183>k<216><20>^<158>A<147><198><5><226><17>
Attributes:
Framed-IP-Address = 207.65.129.158
Service-Type = Framed
Framed-Protocol = PPP
Framed-IP-Netmask = 255.255.255.255
Framed-Compression = Van-Jacobson-TCP-IP
Framed-MTU = 1500
Ascend-Idle-Limit = 1200
Ascend-PPP-Address = 127.0.0.5
Ascend-Maximum-Channels = 1
Ascend-Maximum-Call-Duration = 180
Ascend-Shared-Profile-Enable = Shared-Profile-Yes
OK
As you can see there is now no more duplication.
I am not sure whether the change I made merely suppresses the symptoms or if
it would be a good fix. One thing I should mention is another change we made
to the AuthDYNADDRESS.pm
#####################################################################
# Handle a request
# This function is called for each packet. $p points to a Radius::
# packet
# REVISIT:should we fork before handling. There might be long timeouts?
sub handle_request
{
my ($self, $p, $dummy, $extra_checks) = @_;
my $type = ref($self);
$self->log($main::LOG_DEBUG, "Handling with $type", $p);
my $user_name = $p->getUserName;
if ($p->code eq 'Access-Request')
{
# REVISIT: first confirm that there is no
# address present yet in the reply. yiaddr gives the
# name of the radius attribute where the allocated address
# would be put if we got that far.
return ($main::ACCEPT) # Do nothing
# ALTERTED BY LEON 2002 to only ACCEPT if ip Addres is NEW DYN
if $p->{rp}->get_attr($self->{MapAttribute}{yiaddr}) ne
"255.255.255.254" &&
$p->{rp}->get_attr($self->{MapAttribute}{yiaddr}) ne "";
Etc..
This change makes sure our statically assigned customer will not get an ip
address assigned.
Please let me know whether I'm doing something wrong, or if this is really
undesired behaviour.
Sincerely,
Leon Oosterwijk
ISDN-NET Inc.
(615) 221-4200
http://www.isdn.net
-----Original Message-----
From: Riza Kamalie [mailto:riza at worldonline.co.za]
Sent: Wednesday, May 29, 2002 3:06 AM
To: radiator at open.com.au
Subject: (RADIATOR) Radiator 3.0 - load testing
Hi,
We have just upgraded to radiator 3.0 on a SPARC IIi system using AuthBY
LDAP (which works fine) and
started writing accounting both locally and to a oracleDB hosted to a
seperate server, the problem that
we have encounted it that the performance has decreased some what when
writing to an DB and in turn
causes backlog to the nasses, due to outstanding accounting requests, my
question how do you guys
test load issues against your server re: the performance and tuning table in
the radiator 3 manual?
The way we have do it was using radpwtst -acct_port -noacct to a config
script on port x which wrote accounting
to our database. Using the RADAR real time graph we could see the total
accounting requests it handled was
done poorly by the DB
SQL->Oracle (10000 users)13****
Any input would be appreciated!
Thanks
Riza Kamalie
Systems Administrator
Engineering
Worldonline
A Division of Tiscali (Pty) Ltd
+27 (21) 940 9702
+27(0) 82 992 2027
riza at za.tiscali.com
http://www.worldonline.co.za
If you want your dreams to come true, don't oversleep.
===
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.
More information about the radiator
mailing list