Hello Leon -
In your case I would add an additional Handler that looks for the Framed-IP-Address and then add a StripFromRequest to the Handler. regards Hugh On Tue, 26 Mar 2002 07:42, Leon Oosterwijk wrote: > Hugh, > > > Will using the separate handlers for Accounting and authentication still > clear the state on addresses in the RADPOOL table? Or would I need to put > my authBy DYNADDRESS In both the accounting and authentication handler? > > I was able to implement the solution below by using AuthByGroup. The only > problem I ran into with the AuthBy DYNADDRESS is that this AuthBy Handler > returns ACCEPT if it detects that the request packet already has a > Framed-IP-Address set. This behaviour that not what I wanted because I > wanted my downstream Radius servers to not have to change anything in their > setup. They were passing Framed-IP-Address=255.255.255.254 for dynamically > assigned addresses and Framed-IP-Address=10.10.10.10 for static customers. > I did not want to lose this functionality to I made a modification to the > AuthDYNADDRESS.pm Perm Module. > > Here's the Diff: > > 187,188c187,191 > < return ($main::ACCEPT) # Do nothing > < if $rp->get_attr($self->{MapAttribute}{yiaddr}); > --- > > > return ($main::ACCEPT) # Do nothing > > # ALTER: BY LEON Oosterwijk March 2002 to only ACCEPT if ip > > Addres > > attribute is there and is not dynamic > > > if $rp->get_attr($self->{MapAttribute}{yiaddr}) ne > > "255.255.255.254" && > > > $rp->get_attr($self->{MapAttribute}{yiaddr}) ne ""; > > As you can see the routine now only returns ACCEPT if the yiaddr attribute > is not only there, but is set to an address other than 255.255.255.254. > > This seems to work quite nicely. The only potential problem is that reply > packets could have Framed-IP-Address set twice. Our Ascend MAX TNT units > only listen to the last occurance of an attribute to this works nicely. > > > <Handler Realm=ippool.isdn.net> > RewriteUsername s/^([^@]+).*/$1/ > RewriteUsername tr/A-Z/a-z/ > AuthByPolicy ContinueWhileAccept > <AuthBy SQL> > . . . #authentication > </AuthBy> > <AuthBy GROUP> > AuthByPolicy ContinueAlways > # this always returns reject > <AuthBy SQL> > . . . # Accounting > </AuthBy> > # this always returns accept (unless no more addresses in > pool) > <AuthBy DYNADDRESS> > . . . > </AuthBy> > </AuthBy> > </Handler> > > > > Sincerely, > > Leon Oosterwijk > ISDN-NET Inc. > www.isdn.net > +1 615-221-4200 > > > -----Original Message----- > > From: Hugh Irvine [mailto:[EMAIL PROTECTED]] > > Sent: Monday, March 25, 2002 2:01 PM > > To: Leon Oosterwijk; '[EMAIL PROTECTED]' > > Subject: Re: (RADIATOR) Three Authby Clauses and why they don't work > > > > > > > > Hello Leon - > > > > It is *much* easier to do this sort of thing with separate > > Handlers for > > authentication and accounting. > > > > > > <Handler Request-Type = Accounting, Realm=ippool.isdn.net> > > # do accounting > > ..... > > </Handler> > > > > <Handler Realm=ippool.isdn.net> > > # do authentication > > ..... > > </Handler> > > > > ...... > > > > regards > > > > Hugh > > > > On Tue, 26 Mar 2002 02:24, Leon Oosterwijk wrote: > > > Hugh, > > > > > > I'm trying to set up the address allocation by using Radiator. I'm > > > running into the following problem. The goodies directory indicates > > > that the authby DYNADDRESS needs to be the last authby handler in a > > > realm. This however causes problems for me. > > > > > > In the setup showed below the accounting needs to go to one > > > > database, > > > > > while the auth happens in a different database. This means that the > > > original setup whas AuthByPolicy ContinueAlways. This will > > > > not work if > > > > > the DynAddress is the last auth by clause because the result would > > > always be an accept. However if it say continueWhileAccept > > > > the first > > > > > AuthBySQL, the one that just does accounting will return access > > > denied, and that is the end of the processing. What can be > > > > done to fix > > > > > this problem? > > > > > > Concider the following AuthBy clause > > > > > > #******************************************************************* > > > # TEST - leon's ip pool test ippool.isdn.net > > > #******************************************************************* > > > <Handler Realm=ippool.isdn.net> > > > RewriteUsername s/^([^@]+).*/$1/ > > > RewriteUsername tr/A-Z/a-z/ > > > # AuthByPolicy ContinueAlways > > > AuthByPolicy ContinueWhileAccept > > > > > > > > > <AuthBy SQL> > > > # Adjust DBSource, DBUsername, > > > > DBAuth to suit > > > > > your DB > > > DBSource > > > > dbi:dbtype:dbname:host=10.10.10.10 > > > > > DBUsername user > > > DBAuth pass > > > FailureBackoffTime 60 > > > # Empty Auth Select because this AuthBy is > > > only for Accounting > > > AuthSelect > > > #We only want stop records > > > AccountingStopsOnly > > > # You may want to tailor these for your > > > ACCOUNTING table > > > AccountingTable ACCOUNTING > > > AcctColumnDef USERNAME,User-Name > > > AcctColumnDef TIME_STAMP,Timestamp,integer > > > AcctColumnDef > > > ACCT_DATE,Timestamp,formatted-date,'%Y-%m-%d' > > > AcctColumnDef > > > ACCT_TIME,Timestamp,formatted-date,'%H:%M:%S' > > > AcctColumnDef > > > > ACCTSTATUSTYPE,Acct-Status-Type > > > > > AcctColumnDef > > > ACCTDELAYTIME,Acct-Delay-Time,integer > > > AcctColumnDef > > > ACCTINPUTOCTETS,Acct-Input-Octets,integer > > > AcctColumnDef > > > ACCTOUTPUTOCTETS,Acct-Output-Octets,integer > > > AcctColumnDef > > > > ACCTSESSIONID,Acct-Session-Id > > > > > AcctColumnDef > > > ACCTSESSIONTIME,Acct-Session-Time,integer > > > AcctColumnDef > > > ACCTTERMINATECAUSE,Acct-Terminate-Cause > > > AcctColumnDef NASIDENTIFIER,NAS-IP-Address > > > AcctColumnDef NASPORT,NAS-Port,integer > > > AcctColumnDef > > > > FRAMEDIPADDRESS,Framed-IP-Address > > > > > AcctColumnDef > > > DisconnectCause,Ascend-Disconnect-Cause,integer > > > AcctColumnDef > > > ConnectProgress,Ascend-Connect-Progress,string > > > AcctColumnDef > > > > CallingStationId,Calling-Station-Id > > > > > AcctColumnDef > > > > CalledStationId,Called-Station-Id > > > > > </AuthBy> > > > > > > <AuthBy SQL> > > > # Adjust DBSource, DBUsername, > > > > DBAuth to suit > > > > > your DB > > > DBSource dbi:dbtype:dbname > > > DBUsername user > > > DBAuth pass > > > # 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 > > > </AuthBy> > > > > > > # AuthBy DYNADDRESS needs to be the last AuthBy. If > > > # all the previous ones have succeeded, then an address > > > # is allocated > > > <AuthBy DYNADDRESS> > > > # This refers to the AddressAllocator > > > # defined below. IT says tyo us that allocator > > > # to get an address. Insterad ofg this, you can > > > # put the <AddressAllocator xxx> clause directly > > > # in here > > > Allocator PoolAllocator > > > > > > # This specifies how to form the pool hint, that > > > # the allocator uses to specifiy which pool > > > # to allocate an address from. The default > > > # is %{Reply:PoolHint}, ie a pseudo > > > # attribute in teh current reply, > > > # presumably set by an earlier > > > # AuthBy, but it could be for example > > > # the NAS IP address or similar, or a hardwired > > > # string. > > > #PoolHint %{Reply:PoolHint} > > > # hard code the pool hint. > > > PoolHint 1 > > > > > > # These parameters tell us how to set reply > > > # attribtues from the result of the allocation. > > > # The left hand side of each pair is > > > # the "name" of the data item. The right hand > > > # side is the Radius attribute name to use > > > # in the reply. The valid data item names are: > > > # yiaddr - The allocated address > > > # subnetmask - The subnet mask to use > > > # dnsserver - the IP address of the DNS server > > > # The defualt mappings are: > > > #MapAttribute yiaddr, Framed-IP-Address > > > #MapAttribute subnetmask, Framed-IP-Netmask > > > > > > # The AuthBy FILE above sets the pseudo > > > > reply attribute > > > > > # PoolHint as the clue to the address allocator > > > # need to strip it out at the end of processing > > > > > > #StripFromReply PoolHint > > > # do not need to strip. we never added the poolhint > > > > > > </AuthBy> > > > </Handler> > > > > > > > > > Sincerely, > > > > > > Leon Oosterwijk > > > === > > > 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. -- 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.