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:[EMAIL PROTECTED]] > Sent: Wednesday, April 03, 2002 9:41 AM > To: Leon Oosterwijk; '[EMAIL PROTECTED]' > 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:[EMAIL PROTECTED]] > Sent: Wednesday, April 03, 2002 10:07 AM > To: '[EMAIL PROTECTED]' > 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: '[EMAIL PROTECTED]' > > 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@memrad04 raddb]# radpwtst -user [EMAIL PROTECTED] > > -password clv2526 -noacct -trace > > Code: Access-Request > > Identifier: 145 > > Authentic: 1234567890123456 > > Attributes: > > User-Name = "[EMAIL PROTECTED]" > > 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 = "[EMAIL PROTECTED]" > > 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 [EMAIL PROTECTED], > > 203.63.154.1, 1234 Tue Apr 2 17:44:40 2002: DEBUG: do query > > is: delete from RADONLINE where > > USERNAME='[EMAIL PROTECTED]' 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 [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
