(RADIATOR) RE: Goin' Crazy
Hugh Irvine
hugh at open.com.au
Wed Apr 3 16:48:47 CST 2002
Hello Leon -
There is an example in the file "goodies/hooks.txt" that already does exactly
what you want - you shouldn't have to write anything.
The hook itself is evaluated once only at startup time and there is very
little overhead, especially compared to the database access.
regards
Hugh
On Thu, 4 Apr 2002 06:17, Leon Oosterwijk wrote:
> Frank,
>
> Thanks for the tip. I guess I will have to buckle down and write the hook.
> Hugh had already given me this advice last week. If I do have to write the
> hook, is it compled on radiator startup, or is it evaled on use? I'm just
> curious how much of a performance hit the hook would incur. I guess it
> would probably be less than the sync-fork method though.
>
> Sincerely,
>
> Leon Oosterwijk
> ISDN-NET Inc.
> www.isdn.net
> +1 615-221-4200
>
> > -----Original Message-----
> > From: Frank Danielson [mailto:fdanielson at dataonair.com]
> > Sent: Wednesday, April 03, 2002 9:41 AM
> > To: Leon Oosterwijk; 'radiator at open.com.au'
> > Subject: RE: (RADIATOR) RE: Goin' Crazy
> >
> >
> > Instead of using fork and synchronous you should probably
> > look into doing the AuthBy DYNADDRESS in a PostReplyHook
> > which gets run after a reply from your remote radius server.
> > There are some examples of performing an AuthBy in a hook in
> > the goodies/hooks.txt file in the distribution.
> >
> > -----Original Message-----
> > From: Leon Oosterwijk [mailto:leon at isdn.net]
> > Sent: Wednesday, April 03, 2002 10:07 AM
> > To: 'radiator at open.com.au'
> > Subject: (RADIATOR) RE: Goin' Crazy
> >
> >
> > Ok,
> >
> > I think I might have some more information on this. The
> > problem seems to be the AuthBy Radius. It does not do
> > Synchronous by default. Instead, it processes the
> > AuthByRadius, sends a packet and moves on.
> >
> > From the manual:
> > "Important Note : Normally, an AuthBy RADIUS clause will
> > complete as soon as the request has been forwarded to the
> > remote radius server. It will not wait for a reply before
> > moving on to other AuthBy clauses, or handling new requests.
> > You can change this behaviour with the Synchronous flag, but
> > make sure you understand what you are doing before enabling
> > the Synchronous flag. It can have a significant impact on
> > performance."
> >
> > If the AuthByPolicy is ContinueWhileAccept the second clause
> > (see my config example below) will not get processed, because
> > there was no accept from the radius server.
> >
> > I was able to get the results I wanted by adding fork and
> > synchronous to the AutBy RADIUS clause. This behaviour is not
> > fully documented in the manual.
> > The next question From owner-radiator at open.com.au Wed Apr 3 16:17:45 2002
Received: (from majordomo at localhost)
by server1.open.com.au (8.11.0/8.11.0) id g33MHjd14251
for radiatorzz-list; Wed, 3 Apr 2002 16:17:45 -0600
X-Authentication-Warning: server1.open.com.au: majordomo set sender to owner-radiator at open.com.au using -f
Received: from entoo.connect.com.au (entoo.connect.com.au [192.189.54.8])
by server1.open.com.au (8.11.0/8.11.0) with ESMTP id g33MHi314247
for <radiator at open.com.au>; Wed, 3 Apr 2002 16:17:44 -0600
Received: from there (acc1-ppp497.bur.dialup.connect.net.au [61.68.120.243])
by entoo.connect.com.au (Postfix) with SMTP
id 7BF55E9D14; Thu, 4 Apr 2002 09:41:22 +1000 (EST)
Content-Type: text/plain;
charset="iso-8859-1"
From: Hugh Irvine <hugh at open.com.au>
Reply-To: hugh at open.com.au
Organization: Open System Consultants
To: "Andy De Petter" <adepette at krameria.net>, radiator at open.com.au
Subject: Re: (RADIATOR) Only specific accounting types
Date: Thu, 4 Apr 2002 10:21:34 +1100
X-Mailer: KMail [version 1.3.1]
References: <200204031207.g33C7Sl20644 at oscar.open.com.au>
In-Reply-To: <200204031207.g33C7Sl20644 at oscar.open.com.au>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Message-Id: <20020403234122.7BF55E9D14 at entoo.connect.com.au>
Sender: owner-radiator at open.com.au
Precedence: bulk
List-Id: <radiator.list-id.open.com.au>
Hello Andy -
It might be better to use Handlers for this:
# define Handler for both Alives and Stops
<Handler Acct-Status-Type = /Alive|Stop/>
.....
</Handler>
......
Otherwise, you should use two AuthBy SQL clauses, one for Alives and the
other for Stops.
Note that you should not mix Realms and Handlers in the same configuration
file, so Realms should be changed to Handlers.
<Realm toto.org>
would become
<Handler Realm = toto.org>
And don't forget that the order of the Handlers is important, with the more
specific appearing in the configuration file before the more general.
regards
Hugh
>
> I was wondering whether it's possible to use both AccountingStopsOnly
> and AccountingAlivesOnly to just take Alive/Stop into account, and no
> starts? Or is there a specific parameter to just accept anything but
> starts (something like NoAccountingStarts or so)?
>
> Thx,
>
> -Andy
--
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.
then is, how severe this will impact my
> > radiator's performance. The Radius log does not indicate
> > where the process spawns off a child for the auth, so It
> > would be hard to me to measure how many spawns I get per minute/hour.
> >
> >
> >
> > Sincerely,
> >
> > Leon Oosterwijk
> > ISDN-NET Inc.
> > www.isdn.net
> > +1 615-221-4200
> >
> > > -----Original Message-----
> > > From: Leon Oosterwijk
> > > Sent: Tuesday, April 02, 2002 5:57 PM
> > > To: 'hugh at open.com.au'
> > > Subject: Goin' Crazy
> > >
> > >
> > > All,
> > >
> > > I'm running into a weird problem with my handlers. I think
> > > I'm going crazy :) .. I might be something really stupid, but
> > > I cannot get this setup to proceed with the second handler in
> > > my GROUP. Any help would be appreciated.
> > >
> > > For the record:
> > > Tue Apr 2 17:44:02 2002: INFO: Server started: Radiator
> > > 2.18.1 on host
> > >
> > >
> > > Concider:
> > >
> > > <AuthBy GROUP>
> > > Identifier ippool-test
> > > # AuthByPolicy ContinueWhileAccept
> > > AuthByPolicy ContinueWhileAccept
> > >
> > > RewriteUsername s/^([^@]+).*/$1/
> > >
> > > <AuthBy RADIUS>
> > > Host 216.153.69.66
> > > Secret secret
> > > Retries 15
> > > RetryTimeout 4
> > >
> > > StripFromReply Proxy-State
> > > StripFromReply Filter-Id
> > > StripFromReply Framed-Routing
> > > AddToReplyIfNotExist Framed-Routing = None
> > >
> > > AddToReplyIfNotExist Service-Type = Framed,
> > > Framed-Protocol = PPP, Ascend-Idle-Limit = 1800, \
> > > Ascend-Maximum-Call-Duration
> > > = 180, Ascend-Maximum-Channels = 2
> > > </AuthBy>
> > >
> > > <AuthBy DYNADDRESS>
> > > Allocator PoolAllocator
> > > #PoolHint %{Reply:PoolHint}
> > > # hard code the pool hint.
> > > PoolHint 36
> > > #MapAttribute yiaddr, Framed-IP-Address
> > > #MapAttribute subnetmask,
> >
> > Framed-IP-Netmask
> >
> > > #StripFromReply PoolHint
> > > # do not need to strip. we never
> > > added the poolhint
> > > </AuthBy>
> > >
> > > </AuthBy>
> > >
> > > <Handler Realm=ippool.isdn.net>
> > > RewriteUsername s/^([^@]+).*/$1/
> > > RewriteUsername tr/A-Z/a-z/
> > >
> > > AuthBy ippool-test
> > > </Handler>
> > >
> > > When I Try to set this, I'm expecting the DYnAddress to
> > > attach my IP information, but what happens:
> > >
> > > [root at memrad04 raddb]# radpwtst -user john at ippool.isdn.net
> > > -password clv2526 -noacct -trace
> > > Code: Access-Request
> > > Identifier: 145
> > > Authentic: 1234567890123456
> > > Attributes:
> > > User-Name = "john at ippool.isdn.net"
> > > 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><231>)<159><154>n2<246><188>8<9><160><216>}x<153>"
> > > sending Access-Request...
> > > OK
> > > Code: Access-Accept
> > > Identifier: 145
> > > Authentic:
> > > <227><148><189><3><235>|hD<188><194><20><252><235><240>{<3>
> > > Attributes:
> > > Ascend-Maximum-Channels = 2
> > > Service-Type = Framed
> > > Framed-Protocol = PPP
> > > Ascend-Idle-Limit = 1800
> > > Ascend-Maximum-Call-Duration = 180
> > >
> > > NO IP Information. The Trace 4 in the logs:
> > >
> > >
> > >
> > > Tue Apr 2 17:44:40 2002: DEBUG: Packet dump:
> > > *** Received from 127.0.0.1 port 1114 ....
> > > Code: Access-Request
> > > Identifier: 145
> > > Authentic: 1234567890123456
> > > Attributes:
> > > User-Name = "john at ippool.isdn.net"
> > > 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><231>)<159><154>n2<246><188>8<9><160><216>}x<153>"
> > >
> > > Tue Apr 2 17:44:40 2002: DEBUG: Check if Handler
> > > Realm=ippool.isdn.net should be used to handle this request
> > > Tue Apr 2 17:44:40 2002: DEBUG: Handling request with
> > > Handler 'Realm=ippool.isdn.net' Tue Apr 2 17:44:40 2002:
> > > DEBUG: Rewrote user name to john Tue Apr 2 17:44:40 2002:
> > > DEBUG: Rewrote user name to john Tue Apr 2 17:44:40 2002:
> > > DEBUG: sessiondb Deleting session for john at ippool.isdn.net,
> > > 203.63.154.1, 1234 Tue Apr 2 17:44:40 2002: DEBUG: do query
> > > is: delete from RADONLINE where
> > > USERNAME='john at ippool.isdn.net' and
> > > NASIDENTIFIER='203.63.154.1' and NASPORT='1234'
> > >
> > > Tue Apr 2 17:44:40 2002: DEBUG: Handling with
> > > Radius::AuthGROUP Tue Apr 2 17:44:40 2002: DEBUG: Rewrote
> > > user name to john Tue Apr 2 17:44:40 2002: DEBUG: Handling
> > > with Radius::AuthRADIUS Tue Apr 2 17:44:40 2002: DEBUG:
> >
> > Packet dump:
> > > *** Sending to 216.153.69.66 port 1645 ....
> > > Code: Access-Request
> > > Identifier: 2
> > > Authentic: 1234567890123456
> > > Attributes:
> > > User-Name = "john"
> > > 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 =
> > > "L<177>,<163><242>7<223>U<143><175><25><224><6>u<251>9"
> > >
> > > Tue Apr 2 17:44:40 2002: DEBUG: Packet dump:
> > > *** Received from 216.153.69.66 port 1645 ....
> > > Code: Access-Accept
> > > Identifier: 2
> > > Authentic:
> >
> > <227><190><177><3><238><21>W<153>\<145>!b,<151><154><172>
> >
> > > Attributes:
> > > Ascend-Maximum-Channels = 2
> > >
> > > Tue Apr 2 17:44:40 2002: DEBUG: Received reply in AuthRADIUS
> > > for req 2 from 216.153.69.66:1645 Tue Apr 2 17:44:40 2002:
> > > DEBUG: Access accepted for john Tue Apr 2 17:44:40 2002:
> > > DEBUG: Packet dump:
> > > *** Sending to 127.0.0.1 port 1114 ....
> > > Code: Access-Accept
> > > Identifier: 145
> > > Authentic: 1234567890123456
> > > Attributes:
> > > Ascend-Maximum-Channels = 2
> > > Service-Type = Framed
> > > Framed-Protocol = PPP
> > > Ascend-Idle-Limit = 1800
> > > Ascend-Maximum-Call-Duration = 180
> > >
> > >
> > > Sincerely,
> > >
> > > Leon Oosterwijk
> > > ISDN-NET Inc.
> > > www.isdn.net
> > > +1 615-221-4200
>
> ===
> 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