(RADIATOR) RE: Goin' Crazy
Leon Oosterwijk
leon at isdn.net
Thu Apr 4 10:33:12 CST 2002
Hugh,
I did use the example in the goodies. I had to make some changes. It's good
to know that the hook get's evaled just once. The DynAddress thing seems to
be working quite nicely now. I've got one big problem still. I know we
talked about this earlier, and I still have not found a good solution.
When someone dials in with two channels RADIATOR will assign an IP address
for each channel. This if course is a waste of IP's, as the second channel
doesn't need an IP. I'm trying to find a way to keep radiator from assigning
an IP for the second Access Request but I'm not having much luck. I compared
the Access Requests for the 1st channel session and the 2nd channel session.
I'm adding them to this email at the bottom. As you will see there is really
no difference between the two. The only thing I can think of would be to run
a script every so often that goes through and cleans up IP's that were
assigned to 2nd channels. The only problem with that is, how can you tell
what IP is a second channel IP? There is only the implicit verification if
the IP is not showing up in the RADONLINE table. Anyway, I'm sure I will
think of something but it might be a good discussion
Thu Apr 4 04:02:31 2002: DEBUG: Packet dump:
*** Received from 207.65.53.5 port 1789 ....
Code: Access-Request
Identifier: 13
Authentic: <185><6><188><255><31><182><2><249>Y<202><137>i[<196>l8
Attributes:
User-Name = "autobodybartlett"
User-Password = "W[<243><171><144>"
NAS-IP-Address = 207.65.53.5
NAS-Port = 17
NAS-Port-Type = Sync
Service-Type = Framed
Framed-Protocol = PPP
State = ""
Calling-Station-Id = "9019372425"
Called-Station-Id = "3122721"
Acct-Session-Id = "367167977"
Ascend-Data-Rate = 64000
Ascend-Xmit-Rate = 64000
Thu Apr 4 04:02:47 2002: DEBUG: Packet dump:
*** Received from 207.65.53.5 port 1785 ....
Code: Access-Request
Identifier: 17
Authentic: tQ<242><168><228>W<30>0<11><135><245><229><247><170><23>4
Attributes:
User-Name = "autobodybartlett"
User-Password = "<222>+%G~"
NAS-IP-Address = 207.65.53.5
NAS-Port = 148
NAS-Port-Type = Sync
Service-Type = Framed
Framed-Protocol = PPP
State = ""
Calling-Station-Id = "9019372426"
Called-Station-Id = "3122721"
Acct-Session-Id = "367167979"
Ascend-Data-Rate = 64000
Ascend-Xmit-Rate = 64000
Sincerely,
Leon Oosterwijk
ISDN-NET Inc.
www.isdn.net
+1 615-221-4200
> -----Original Message-----
> From: Hugh Irvine [mailto:hugh at open.com.au]
> Sent: Wednesday, April 03, 2002 4:49 PM
> To: Leon Oosterwijk; 'Frank Danielson'
> Cc: 'radiator at open.com.au'
> Subject: Re: (RADIATOR) RE: Goin' Crazy
>
>
>
> 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 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