(RADIATOR) RE: Goin' Crazy
Leon Oosterwijk
leon at isdn.net
Thu Apr 4 11:28:40 CST 2002
All,
I don't know why I keep answering my own questions. :) The easier way I
could find to state=0 the ip's that were assigned on the second channel
authentication is by using the following queries.
SELECT RADPOOL.YIADDR from RADPOOL LEFT OUTER JOIN RADONLINE ON
RADONLINE.FRAMEDIPADDRESS = RADPOOL.YIADDR WHERE STATE = 1 AND
RADONLINE.FRAMEDIPADDRESS IS NULL;
UPDATE RADPOOL SET STATE = 0 WHERE YIADDR =;
The first one returns all ip's that are currently not in use according to
the RADONLINE table. Because we use MYSQL 3.x we cannot do Subselects. I'm
using a little bit of perl code to iterate over the ip's and execute query
#2 that does the state =0 update. I'm already running some scripts to keep
the RADONLINE table clean, so I just attached this code to the end of my
script. Not the prettiest solution, but definatly the easiest/fastest.
Sincerely,
Leon Oosterwijk
ISDN-NET Inc.
www.isdn.net
+1 615-221-4200
> -----Original Message-----
> From: Leon Oosterwijk [mailto:leon at isdn.net]
> Sent: Thursday, April 04, 2002 10:33 AM
> To: 'hugh at open.com.au'; Leon Oosterwijk
> Cc: 'radiator at open.com.au'
> Subject: RE: (RADIATOR) RE: Goin' Crazy
>
>
> 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