Hello Leon -
Your understanding of what Radiator does in this case is incorrect.
If the AuthBy DYNADDRESS clause sees that there is a Framed-IP-Address
already present in the reply packet, it leaves it alone and does not do any
address allocation. This is to allow specific user definitions with a fixed
IP address to take precedence.
>From section 6.42.3 in the Radiator 3.1 reference manual.
MapAttribute
This optional parameter allows you to specifiy how the results of the
address allocation are to be placed in the reply. If the yiaddr attribute
(usually Framed-IP-ADdress) is already set in the reply, then AuthBy
DYNADDRESS will not allocate an addresss, and will just ACCEPT the request.
This means that if a user record has a fixed IP address in it, then AuthBy
DYNADDRESS will not allocate an address for that user.
To say any more, I will need to see the complete configuration file, and the
relevant SQL database records.
regards
Hugh
On Fri, 31 May 2002 04:31, Leon Oosterwijk wrote:
> 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@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@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:[EMAIL PROTECTED]]
> Sent: Wednesday, May 29, 2002 3:06 AM
> To: [EMAIL PROTECTED]
> 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
> [EMAIL PROTECTED]
> 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 [EMAIL PROTECTED]
> To unsubscribe, email '[EMAIL PROTECTED]' with
> 'unsubscribe radiator' in the body of the message.
--
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.
===
Archive at http://www.open.com.au/archives/radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
