Re: (RADIATOR) Current Logged in Users
Hello Rolando - On Tue, 12 Feb 2002 01:03, Rolando Riley wrote: > When I say 'fairly accurate' - if your NAS fails to deliver a STOP record > to radiator, the user will not be removed from the online users database. > > > The above seems to be very common to happen. That is > > 1) hanged users which can't auth because of a Max Sessions reached and no > STOP record sent by the NAS has been taken > 2) Sometimes hanged RADIUS. That still happens to us when we change all the > auths to LDAP. And it is due to the same cause in point 1) > > My question is: > 1) what is the accurate way to use scripts like scripts like > goodies/cleanup.txt or checksessiondb.txt These scripts are designed to be run periodically from cron or similar. > 2) do you know what are the frequent causes that make NAS don't send the > STOP record ? > The two most frequent causes are congested links dropping UDP packets or NAS software bugs that don't send them at all. regards Hugh -- 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.
Re: (RADIATOR) Acct-Session-Time = 0?
Hello Neil - This is really a question for your NAS vendor - sounds like a bug to me. regards Hugh On Tue, 12 Feb 2002 08:54, neil d. quiogue wrote: > Hello, > > Does anyone have an idea on what can cause the Acct-Session-Time to be 0? > I saw two types of Terminate-Causes: User-Request and Host-Request. Just > curious that if a user disconnects it, then it should still take a few > seconds right? > > Any insight on this would be greatly appreciated. Much thanks. > > Regards, > > Neil D. Quiogue > > === > 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.
Re: (RADIATOR) ERR: Unknown keyword 'AddToRequest'
Hi Dave - You are correct again - this *is* a Handler parameter (I mistook it for AddToReply). However it is only supported in Radiator 2.19 and later. My apologies. regards Hugh On Tue, 12 Feb 2002 00:37, Dave Kitabjian wrote: > Oh, thanks. Note, however that: > > 6.16.19 AddToRequest > > is in the Handler section of the docs. Meanwhile, let me see if I can > move my logic into an AuthBy... However, AddToRequest would make a > useful Handler attribute :) > > Dave > > > -Original Message- > > From: Hugh Irvine [mailto:[EMAIL PROTECTED]] > > Sent: Friday, February 08, 2002 7:20 PM > > To: Dave Kitabjian; [EMAIL PROTECTED] > > Subject: Re: (RADIATOR) ERR: Unknown keyword 'AddToRequest' > > > > > > > > Hello Dave - > > > > AddToRequest is an AuthBy parameter, not a Handler parameter. > > > > regards > > > > Hugh > > > > On Sat, 9 Feb 2002 03:56, Dave Kitabjian wrote: > > > I'm getting: > > > > > > ERR: Unknown keyword 'AddToRequest' in > > > > /usr/radiator/nc.cfg line 772 > > > > > in my Handler: > > > > > > > > > > > > AuthBy IPASS > > > > > > AddToRequest NC-Ipass-Flag = 1 > > > AcctLogFileName %D/Accounting/IPASS_OUTBOUND-%h > > > > > > AuthLog AUTH_LOGGER > > > PasswordLogFileName %L/password.log > > > > > > > > > > > > We're running 2.18. Does anyone know if this keyword was new to > > > Handlers since 2.18? I didn't remember reading about it... > > > > > > _ > > > > > > Dave Kitabjian > > > NetCarrier, Software Engineering > > > > -- > > 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. -- 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.
Re: (RADIATOR) Overriding NAS
Hello Rolando -
On Tue, 12 Feb 2002 08:23, Rolando Riley wrote:
> Hi Hugh:
> I want to say that AuthBy DYNADDRESS work excellent so far for what I need
> =)). Although I've got some doubts from my tests.
>
> 1) I noticed that when I ran radpwtst like the following:
>
> /usr/local/src/radius/radpwtst -user rriley -password yo -framed_ip_address
> 168.77.14.2 -calling_station_id 2652424
>
> the STOP record doesn't delete the record from the RADPOOL table. That is..
> it doesn't free the IP that was assigned to the user after it finished the
> session?
>
The IP address is being deleted, however it is the wrong address because you
have overridden the address being used on the radpwtst command line.
ie. -framed_ip_address 168.77.14.2 is what is being used
Have another look at the trace 4 debug to see what I mean.
>
> 2) I wish I could use instead ofto link a
> user to a pool =) . What attribute should I use in this case to make the
> same effect to get the PoolHint?
>
You can use an - you just need an additional reply attribute
as described in section 6.35 of the Radiator 2.19 reference manual.
> 3) I believe the bellow lines are in charge to send back to the NAS the
> NEW values of IP and mask for the user right?
>
> PoolHint %{Reply:PoolHint}
> MapAttributeyiaddr, Framed-IP-Address
> MapAttributesubnetmask, Framed-IP-Netmask
>
Correct.
regards
Hugh
--
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.
Re: (RADIATOR) Current Logged in Users
Hi Shane - Just add this code to the bottom of your radius.cfg file (or whatever you call yours) DBSource dbi:ODBC:RadiusLog DBUsername radiususer DBAuth radiususerpassword Where : - RadiusLog is your ODBC datasource setup for Radiator (you probably already have this for authentication and accounting - use the same one) - radiususer is the SQL user account with access to the above datasource - radiususerpassword is the above users password for accessing the SQL datasource You should have/create a table within the above database called RADONLINE its structure and details can be found in the goodies section. Use the suggested structure for now (that way you can accept the defaults) but you can add to it to record additional helpful info later if you want. Regards, Brian Morris - Original Message - From: Shane Malden To: Brian Morris Sent: Monday, February 11, 2002 4:10 PM Subject: Re: (RADIATOR) Current Logged in Users Thanks for this. Do you use NT and SQL yourself or just know Radiator fairly well?? Do you have any sample code on how so get Radiator to log this information?? Regards, Shane - Original Message - From: Brian Morris To: Shane Malden ; [EMAIL PROTECTED] Sent: Monday, February 11, 2002 3:22 PM Subject: Re: (RADIATOR) Current Logged in Users If you are using an SQL back-end database, the RADONLINE table contains a fairly accurate list of all users currently online. When I say 'fairly accurate' - if your NAS fails to deliver a STOP record to radiator, the user will not be removed from the online users database. - Original Message - From: Shane Malden To: [EMAIL PROTECTED] Sent: Monday, February 11, 2002 2:59 PM Subject: (RADIATOR) Current Logged in Users Does anyone know any simple way of seeing who is logged on, using the logs from Radiator? We do receive start and stops from our gear. We are running ver 2.19 on a NT Server. Any help would be appreciated. Regards, Shane
Re: (RADIATOR) Acct-Session-Time = 0?
We get tons of these with Ascend-Disconnect-Cause = 46 when 64k ISDN customers misconfigure thier end and keep trying to bring up the second channel. Every few seconds, their second channel will connect, authenticate, and disconnect, resulting in lots of Acct-Session-Time = 0 sessions. On Tue, 12 Feb 2002, Hugh Irvine wrote: > > Hello Neil - > > This is really a question for your NAS vendor - sounds like a bug to me. > On Tue, 12 Feb 2002 08:54, neil d. quiogue wrote: > > Hello, > > > > Does anyone have an idea on what can cause the Acct-Session-Time to be 0? > > I saw two types of Terminate-Causes: User-Request and Host-Request. Just > > curious that if a user disconnects it, then it should still take a few > > seconds right? > > > > Any insight on this would be greatly appreciated. Much thanks. > > > > Regards, > > > > Neil D. Quiogue > > > > === > > 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. > > -- -- Jon Lewis *[EMAIL PROTECTED]*| I route System Administrator| therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_ === 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.
Re: (RADIATOR) strange authlog behavior (bug?)
Hello Sam - Can you send me a copy of your configuration file (no secrets) together with a trace 4 debug showing what happens in both cases? And what version of Radiator are you running and on what hardware/software platform? thanks Hugh On Tue, 12 Feb 2002 10:25, Sam Nilsson wrote: > We are using individual authlog clauses for our handlers. > These look like this... > > > Filename /path/to/logs/%R/%R_auth_%m%d%Y.log > LogSuccess 1 > LogFailure 1 > > > When we kill -HUP the radius process, the new handler that > we've added begins working properly. However, the authlog > doesn't get created or written to. > > After killing the process (not hupping it) and then starting radiator > again, the authlog magically starts working. > > I may be missing something, but this appears to be a bug in the way > radiator handles a HUP signal. > > Has anyone else seen this? Can anyone confirm or deny this? > > - Sam > > === > 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.
