(RADIATOR) RE: Goin' Crazy

Leon Oosterwijk leon at isdn.net
Thu Apr 4 12:35:32 CST 2002


Ronan, 

This would work great if I had control over the user profiles and knew which
ones were ISDN. Unfortunately we are the proxy host for a large amount of
different providers. The people that use ISDN and bond and those that don't
difer per day. 

Sincerely,

Leon Oosterwijk
ISDN-NET Inc. 
www.isdn.net
+1 615-221-4200 

> -----Original Message-----
> From: Ronan Eckelberry [mailto:radiator at gowebco.com] 
> Sent: Thursday, April 04, 2002 12:04 PM
> To: 'Leon Oosterwijk'; hugh at open.com.au
> Cc: radiator at open.com.au
> Subject: RE: (RADIATOR) RE: Goin' Crazy
> 
> 
> 	You would use the PORTLIMIT Reply Attribute for that.  
> For example an ISDN would have a PORTLIMIT of 2 and both 
> channels would be assigned the same IP address.
> 
> -Ronan
> 
> 
> -----Original Message-----
> From: owner-radiator at open.com.au 
> [mailto:owner-radiator at open.com.au] On Behalf Of Leon Oosterwijk
> Sent: Thursday, 04 April, 2002 11:33
> 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.
> 
===
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