No subject
Tue Jun 24 01:20:08 CDT 2008
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 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.
--
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 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