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:[EMAIL PROTECTED]] > Sent: Thursday, April 04, 2002 10:33 AM > To: '[EMAIL PROTECTED]'; Leon Oosterwijk > Cc: '[EMAIL PROTECTED]' > 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:[EMAIL PROTECTED]] > > Sent: Wednesday, April 03, 2002 4:49 PM > > To: Leon Oosterwijk; 'Frank Danielson' > > Cc: '[EMAIL PROTECTED]' > > 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:[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. > > > > -- > > 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 [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
