Re: (RADIATOR) Stopping people using ISDN
On Wed, 13 Sep 2000, Raymond Brighenti wrote:
> Hi,
>
> What I'm after is a way to stop people using ISDN to connect to our Maxs,
> I'm only using in my config so would changing it toNAS-Port-Type=Async> be the best way about this or is there a better way of
> handling this?
I control it on a per user basis from within my database. I also control
whether or not users can bond 2 channels or can only have 1 connection
through the database. Here is how I handle it:
RewriteUsername s/^([^@]+).*/$1\@somedomain.com/
RewriteUsername tr/A-Z/a-z/
AuthByPolicy DoAllAuths
AuthBy SQLAccountingStart
AuthBy SQLAccountingStop
AuthBy SQLAccountingETC
AuthBy SQLAccountingETCETC
# The following file will have a default entry which
# specifies to use the "SQLAuthISDN" authentication defined
# in a block later in this file
Filename %D/usersISDN
#
# This block is referenced in the "usersISDN" file
# it is then used to do the authentication.
#
Identifier SQLAuthISDN
DBSource dbi:mydbd:mydbname:mydbhost
DBUsername dbusername
DBAuth dbpassword
AuthSelect \
SELECT passwd,check_items,reply_items, \
concat('Simultaneous-Use = ',sim_use),\
IF(status<3,'','Auth-Type = "Reject:Account blocked"'),
IF(active=1,'','Auth-Type = "Reject:Account inactive"'),
IF(useISDN=1,'','Auth-Type = "Reject:ISDN Access disabled"') \
FROM users \
WHERE (userid='%U')
EncryptedPassword
AuthColumnDef 0, Encrypted-Password, check
AuthColumnDef 1, GENERIC, check
AuthColumnDef 2, GENERIC, reply
AuthColumnDef 3, GENERIC, check
AuthColumnDef 4, GENERIC, check
AuthColumnDef 5, GENERIC, check
AuthColumnDef 6, GENERIC, check
Then within my raddb/usersISDN file I have:
DEFAULT Auth-Type = SQLAuthISDN
Service-Type = Framed-User,
Framed-Protocol = PPP,
Framed-IP-Address = 255.255.255.254,
Framed-IP-Netmask = 255.255.255.255,
Framed-Routing = None,
Framed-Compression = Van-Jacobson-TCP-IP
I hope that is helpful. Remember that is just the way I do it. Radiator is
VERY flexible and I am sure there are many other ways to do it.
Steve
===
Archive at http://www.starport.net/~radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) MySQL & Oracle
On Tue, 8 Feb 2000, Yang Tercepat wrote: > My question is: > 1. is anyone have this problem before and have solution for >this situation? > 2. it is safe to run MySQL without lock option? > 3. how much is the maximum client should Radiator handled, for >the best performance using Oracle database? > 4. it is better to run Radiator on the same machine with >Oracle server on Sun or should be separated? First of all it is my understanding that MySQL is significantly faster than Oracle, which is probably why your Oracle server is having trouble with the volume. With that said, the way that we handle the problem is that we have a temporary table to all of the login records are written to. Then a seperate process copies all of the records from the temporary table to the permanent table. This process happens every 60 seconds so there are usually less than 200 records in the temporary table at any time. All queries are done on the permanent table so radius is never locked out from writing records. The most important thing to do is run at least 2 DB servers. One which handle authentication and one which handle accounting. In addition run two radius processes, on for authentication and one for accounting. This way your accounting records will never hold up the radius server from authenticating anyone. In actual practice I think that you will find that your RAS will start having problems as your accounting backs up, even if authentication is going through. You will also start to see a lot of duplicates. Steve --- Steve Roderick ProAxis Communications, Inc. [EMAIL PROTECTED] Internet Access Provider (541) 757-0248 === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) finger problem
On Fri, 11 Jun 1999, Mike McCauley wrote: > Hello Ferhat. > > What NasType are you using, and what does your finger say when it times out? > Try running it by hand, to see. > > With that information, we might be able add a patch that will detect a timeout > and not delete the user. The BIG problem isn't deleting the user, it is the HUGE delay that occurs while Radiator is trying to verify the user. This stops all other authentications, and when you are running a lot of ports it is disastrous. Steve --- Steve Roderick ProAxis Communications, Inc. [EMAIL PROTECTED] Internet Access Provider (541) 757-0248 === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) finger problem
On Fri, 11 Jun 1999, Ferhat Dilman wrote: > Radiator is in location Istanbul for example, and one of the POP's are in > other city e.g. Ankara. When the line goes down between Istanbul-Ankara, and > the user tries to logon in Istanbul, since the user information still on > RADONLINE, it tries to check it thru finger and since the line is down, > finger WAITS! a longtime thus Radiator does not respond other requests till > the finger request is finished (single process that is). > > Then eventually finger timeouts and the session is deleted from RADONLINE > and user is permitted. However this has two problems: > 1- User may be still online in Ankara (thus simultanous sessions) > 2- finger waits too long and no user auth is accepted till timeout of finger > > Any solutions to finger problem when the line is down? How can we > automatically cancel finger requests if the line is down between POP and > Radiator-Host location? This is a problem that I posted about a while ago. Unfortunately when Mike asks if this is a problem for anyone else, everyone is silent. The solution: Radiator needs to be able to fork at the time that it is going to verify a login. Steve --- Steve Roderick ProAxis Communications, Inc. [EMAIL PROTECTED] Internet Access Provider (541) 757-0248 === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Ascend Max TNT?
On Fri, 11 Jun 1999, Mike McCauley wrote: > Hello Hielke, > > On Jun 10, 5:34pm, Hielke Christian Braun wrote: > > Subject: (RADIATOR) Ascend Max TNT? > > Hi everybody, > > > > does anybody use a Ascend Max TNT with radiator server? > > I have the problem that the Max TNT's try to authenticate > > some strange users like appleroute-tnt01-1, pools-tnt01, > > permconn-tnt01-1, frdlink-tnt01-1 and so on. The radiator > > server does not know about them and rejects them. But > > the Max TNT's keep on trying to authenticate. Maybe somebody > > can mail a config or users file for the radiator? > > Looks to me like the TNT is trying to get some of its configuration from the > radius server. Im not an Ascend expert so I cant tell you too much about this. > > Anyone else? Just ignore them. I think we get these about once a week or every few days, once the box is up and running correctly. I think that Ascend Radius lets you control this stuff (bad idea in my opinion) Steve --- Steve Roderick ProAxis Communications, Inc. [EMAIL PROTECTED] Internet Access Provider (541) 757-0248 === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) Strange log entries
Anyone know what causes these? Wed Jun 2 02:46:14 1999: INFO: No reply after 3 retransmissions Wed Jun 2 02:46:14 1999: INFO: No response from any RADIUS hosts. Ignoring Repeats every 3 seconds for about a minute or two. Thanks, Steve === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) snmp, mrtg, cfgmaker...
On Fri, 28 May 1999, Mike McCauley wrote: > On May 27, 3:58pm, Ricardo Kustner wrote: > > Subject: Re: (RADIATOR) snmp, mrtg, cfgmaker... > > > > On 27-May-99 Jeremy Hinton wrote: > > > uses different MIBs (take a look at draft-ietf-radius-servmib-04.txt in > > > your Radiator doc dir), cfgmaker wont work with it, but MRTG will. You'll > > > just have to hand-tweek the mrtg cfg files. > > > > to be honest i'm a little lazy does anyone have an example mrtg cfg for > me? > > > > :) > If anyone can provide an example, Ill put it in the faq or somewhere too. I posted an MRTG example a couple weeks ago. Steve --- Steve Roderick ProAxis Communications, Inc. [EMAIL PROTECTED] Internet Access Provider (541) 757-0248 === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Group Maximum
On Thu, 20 May 1999, Mike McCauley wrote: > Hi Stephen, > > Thanks for contributing that!. I know lots of people appreciate it. > > I wonder if you could get the same effect by just changing the definition of > CountQuery in , so it would count the current sessions by > whatever criteria you liked, and MaxSessions would specify the upper limit? > That would have the side effect of continuing to work propoerly with string > authentication too (ie where Radiator uses finger or SNMP to check the NAS) Up until a few days ago I didn't realize that you could have multiple clauses. But with those you could duplicate the same effect with CountQuery. Steve === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) Group Maximum
Another kludge that may be useful to someone:
I added some code to create a group maximum within the session database.
This required a modification to Handler.pm, SessGeneric.pm, and SessSQL.pm
(If you used a different Sess.pm module it would need to be modified
as well)
Then within the I use:
GroupQuery someUniqueName 30 \
select count(*) from radonline \
where ('%{Called-Station-Id}'='XXX')
This would limit the number of connections to the phone number XXX to
30.
You could add as many of these as you wanted and use whatever query
generated the necessary results.
*
Handler.pm - Add the following after the check for MaxSession:
if ($p->code eq 'Access-Request' && $sessdb->groupexceeded($p))
{
# Issue a denial and bomb out
my $reason = "Group Maximum exceeded";
&main::log($main::LOG_INFO, "Access rejected for $name: $reason");
$rp->set_code('Access-Reject');
$rp->addAttrByNum($Radius::Radius::REPLY_MESSAGE,
'Request Denied');
$rp->addAttrByNum($Radius::Radius::REPLY_MESSAGE, $reason)
if $self->{RejectHasReason};
$p->{Client}->replyTo($rp, $p);
return;
}
*
SessGeneric.pm - add the following (this is probably not needed):
sub groupexceeded
{
my ($self, $max, $name, $p) = @_;
&main::log($main::LOG_ERR, "You did not override groupexceeded in
SessGeneric");
}
*
SessSQL.pm - add the following:
elsif ($keyword eq 'GroupQuery')
{
my($id, $count, $q) = split(/\s+/, $value, 3);
$self->{GroupQuery}{$id} = "$count:$q";
}
sub groupexceeded
{
my ($self, $p) = @_;
# (Re)-connect to the database if necessary, but dont let
# a dead database prevent logins
return 0
if !$self->reconnect;
my $count = 0; # Number of current simultaneous sessions for the user
my($id,$max,$q,$sth);
foreach $id (keys %{$self->{GroupQuery}})
{
($max, $q) = split(':', $self->{GroupQuery}{$id});
$q = &main::format_special($q, $p);
$sth = $self->prepareAndExecute($q);
if (!$sth)
{
return 0; # Dont let a dead database stop logins
}
($count) = $sth->fetchrow();
return 1if ($count > $max);
}
return 0;
}
All improvements welcome.
Steve
===
Archive at http://www.thesite.com.au/~radiator/
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
(RADIATOR) Command line options
Mike, Can you add a command line option for -snmp_port so that two processes can run off the same config file and yet still do SNMP. Steve === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Out of Memory (BSDI) Fix
We usually just wrap a shell script around the program and do: #!/bin/csh limit datasize 65536 /usr/local/bin/radiusd & exit 0 Of course the compiled in kernel limits could stop you from raising the limit far enough. Steve === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) MRTG Stats
On Wed, 12 May 1999, Kevin wrote:
>
> Can anyone using MRTG for pulling stats on their Radiator, fill me in on
> what exactly they are able to monitor and how they're going about doing
> it. We currently use MRTG to monitor bandwidth, but I've seen some people
> tweak it for monitoring other interesting stuff...
Well, this is what I do (via a cron job every 5 minutes):
#!/usr/local/bin/perl
$total = 0;
$accttotal = 0;
open(FD, "/usr/local/bin/snmpwalk host community
.1.3.6.1.3.79.1.1.1.6.1.4 |") or die;
while()
{
$total += $1if (/.* = (\d+)/);
}
close(FD);
open(FD, "/usr/local/bin/snmpwalk host community
.1.3.6.1.3.79.1.1.1.6.1.12 |") or die;
while()
{
$accttotal += $1if (/.* = (\d+)/);
}
close(FD);
$total *= 8;
$accttotal *= 8;
open(FD, ">/stats/radius.stats");
print FD "$total\n$total\n";
close(FD);
open(FD, ">/stats/radiusacct.stats");
print FD "$accttotal\n$accttotal\n";
close(FD);
exit 0;
---
Then I have the following config for MRTG:
Target[radiator]: `/bin/cat /stats/radius.stats`
MaxBytes[radiator]: 2000
Options[radiator]: nopercent
Title[radiator]: Radius Statistics
PageTop[radiator]: Radius Statistics
WithPeak[radiator]: dwmy
YLegend[radiator]: No. of queries
ShortLegend[radiator]: queries
LegendI[radiator]: Authentication:
LegendO[radiator]:
#.
Target[radacct]: `/bin/cat /stats/radiusacct.stats`
MaxBytes[radacct]: 2000
Options[radacct]: nopercent
Title[radacct]: Radius Statistics
PageTop[radacct]: Radius Statistics
WithPeak[radacct]: dwmy
YLegend[radacct]: No. of queries
ShortLegend[radacct]: queries
LegendI[radacct]: Accounting:
LegendO[radacct]:
--
I'm sure there is a better way but at some point you get tired of trying
to find it and just do something that works.
Have fun,
Steve
===
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) MAX TNT + SimultaneousUse + AscendSNMP
On Thu, 13 May 1999, Mike McCauley wrote: > What was the problem with $Radius::Nas::AscendMIB.12.2.1.3.$nas_port ? It just didn't work. Perhaps if someone else could try the one I suggested and let us all know if it worked for them. I am using Ascend MAX 6000 boxes but will be using MAX TNT in the future. Perhaps there is a difference on the different boxes and that is why one works for me but the other works for someone else. Steve === To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) MAX TNT + SimultaneousUse + AscendSNMP
On Wed, 12 May 1999, Ian Quorn wrote:
> .iso.org.dod.internet.private.enterprises.529.12.2.1.3.$nas_port
I emailed about this a while ago. I use the following:
$Radius::Nas::snmpgetprog $nas_id $client->{SNMPCommunity}
$Radius::Nas::AscendMIB.12.3.1.4.$session_id
Steve
===
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
(RADIATOR) Missing attribute
Does anyone know what this one is? Attribute number 36901 (vendor 429) Steve === To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) Radiator/Livingston problem
We have a number of Livingston PM-25s that freak out when they are authenticating off of radiator. We are still unable to figure out why but it seems like it is related to radiator response time, especially with regards to accounting packets. Has anyone had similar problems? Our only real evidence is A LOT of duplicate requests and the boxes crashing. If we also attempt to verify multiple logins against these boxes they will typically crash within a day. I know that I don't have a lot of details here, but I was hoping that someone had some similar experiences and could shed some light on the situation. Thanks, Steve === To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Forking
On Thu, 29 Apr 1999, Mike McCauley wrote: > Hi Stephen, > > The Fork keywork works now for most AuthBy modules. However there are dangers > in injudicious use of it: its really there for the use of authentication > modules that really need it and are coded to expect it. What do you want to do? I only want radiator to fork if it is going to try to verify that someone is still logged into a nas. The process of verifying often takes too long and holds up all of the other authentication requests. Steve === To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) Forking
Any idea if we will be able to (in the near future) force radiator to fork when it tries to verify if a user is online? Steve --- Steve Roderick ProAxis Communications, Inc. [EMAIL PROTECTED] Internet Access Provider (541) 757-0248 === To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) pid file
If radiator were to delete its pid file when it went away then it would be easy to write a much better wrapper program, which would just detect the existence of the pid file (similar to mysql). Steve --- Steve Roderick ProAxis Communications, Inc. [EMAIL PROTECTED] Internet Access Provider (541) 757-0248 === To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) Re: your mail
On Thu, 15 Apr 1999, Jamie Orzechowski wrote: > Hi There ... I was wondering if anyone had a config for me that will convert > all usernames to lowercase and also strip off anything after (and including) > the @ symbol ... some people try and login with their [EMAIL PROTECTED] which > will not work ... it will have to do the converting of the name before it is > sent to the accounting server so that it will be accounted for properly ... > any ideas? RewriteUsername s/^([^@]+).*/$1/ RewriteUsername tr/A-Z/a-z/ Steve === To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) SNMP
On Thu, 15 Apr 1999, Mike McCauley wrote: > Does your snmpget default to V1 or V2? > Radiator only supports V1 It supports both, but neither seems to work. Steve === To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) SNMP more info
snmpget -d server public .iso.org.dod.internet.3.79.1.1.1.1 sending 52 bytes to X:161: : 30 82 00 30 02 01 00 04 06 70 75 62 6C 69 63 A0 0..0.public. 0016: 82 00 21 02 04 0F 55 D3 B2 02 01 00 02 01 00 30 ..!...U0 0032: 82 00 11 30 82 00 0D 06 09 2B 06 01 03 4F 01 01 ...0.+...O.. 0048: 01 01 05 00 received 46 bytes from X:161: : 30 2C 02 01 00 04 06 70 75 62 6C 69 63 A2 1F 02 0,.public... 0016: 04 0F 55 D3 B2 02 01 00 02 01 00 30 11 30 0F 04 ..U0.0.. 0032: 0D 52 61 64 69 61 74 6F 72 20 32 2E 31 33 .Radiator 2.13 Unrecognizable or unauthentic packet received Steve === To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) SNMP
snmpget radius.proaxis.com public .iso.org.dod.internet.3.79.1.1.1.1 Unrecognizable or unauthentic packet received Unrecognizable or unauthentic packet received Unrecognizable or unauthentic packet received snmpget -V UCD-snmp version: 3.5 What am I doing wrong? Steve === To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) MRTG
Anyone have a recommended config for MRTG and Radiator with SNMPAgent? Steve === To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) Handlers WOW!
I can't believe this doesn't work: While this does work: Very "uncool" and painful to discover. Ugh. Steve === To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) MS-SQL 7
On Wed, 31 Mar 1999, Kevin Wormington wrote: > Yes, there is a DBD::FreeTDS module that will communicate with SQL 7.0, it > works fine but does not currently implement any error checking (at least > it didn't two weeks ago) which means that "select foo from bar" will > return success even though it's an error. The URL is: http://sunsite.unc.edu/freetds/ Steve === To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) Logging
Are there any plans to improve the logging options? I would really like to be able to log different types of info in different files. i.e. debugging, errors, etc. Which of course would then lead to a request for increased granularity in the types. :-) Steve --- Steve Roderick ProAxis Communications, Inc. [EMAIL PROTECTED] Internet Access Provider (541) 757-0248 === To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Problem with Ascend MAX
On Wed, 31 Mar 1999, Ray Brighenti wrote: > It's not the Backoff Q full error your getting is it? This quite possible may have been the problem. I increased the queue size from 64 to 128. Seems to be working well now. Unfortunately, when you are in crisis mode you change anything you can think of to get it to work. Thus I have no way to pin the solution to the queue size. Steve --- Steve Roderick ProAxis Communications, Inc. [EMAIL PROTECTED] Internet Access Provider (541) 757-0248 === To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Problem with Ascend MAX
On Wed, 31 Mar 1999, Mike McCauley wrote: > Hi Stephen, > > Thats odd. I have only seen that sort of thing on SunOs with older versions of > Radiator (ie before 2.13) > What platform and OS is Radiator on. What version are you running? I'm running 2.13 (with 2.13.1 patches) on BSD/OS 3.1. Steve --- Steve Roderick ProAxis Communications, Inc. [EMAIL PROTECTED] Internet Access Provider (541) 757-0248 === To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) Problem with Ascend MAX
I have an odd problem with an Ascend MAX. Everthing seems to work fine and then all of a sudden it start getting: Radius client timeout (code=1) for user this is in the MAX log (not Radiator) >From what I can tell no requests are coming into Radiator. The other terminal servers seem to be working okay. The problem... if I do a kill -hup on Radiator everything starts working again. Steve --- Steve Roderick ProAxis Communications, Inc. [EMAIL PROTECTED] Internet Access Provider (541) 757-0248 === To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) AscendSNMP
On Mon, 29 Mar 1999, Mike McCauley wrote: > > This will return the name of the user logged in with that session_id. The > > important thing is that it can show the user as "steve" or > > "[EMAIL PROTECTED]" depending on how they logged in. So I was guessing > > that: > > > > if ($result =~ /^.*\"([^"\@]+)["\@].*$/) > > > > I guess that will strip off the realm name, which will match if you are using a > RewriteUsername prior to authentication? That is a really good point. I do use RewriteUsername but I force the @proaxis.com to be added. Of course when you query the nas it is always going to return what the user "really" logged in as, not what RewriteUsername has done. How do you propose we reconcile that? Steve --- Steve Roderick ProAxis Communications, Inc. [EMAIL PROTECTED] Internet Access Provider (541) 757-0248 === To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) TotalControlSNMP
I have figured out the Total Control SNMP stuff as well (see note at
bottom). I'm sure that Mike will whip up a patch for everyone in the near
future.
# The 3com TotalControl SNMP MIB
$Radius::Nas::TCMIB =
'.iso.org.dod.internet.private.enterprises.429'
sub isOnlineTotalControlSNMP
{
my ($name, $nas_id, $nas_port, $session_id, $client) = @_;
if (!-x $Radius::Nas::snmpgetprog)
{
&main::log($main::LOG_ERR, "$Radius::Nas::snmpgetprog is not
executable. Check and configure Nas.pm");
return 1; # Assume the worst
}
my $portidx = 1256 + $nas_port;
my $result = `$Radius::Nas::snmpgetprog $nas_id
$client->{SNMPCommunity} $Radius::Nas::TCMIB.4.10.1.1.18.$portidx`;
&main::log($main::LOG_ERR, "The command '$Radius::Nas::snmpgetprog
$nas_id $client->{SNMPCommunity} $Radius::Nas::TCMIB.4.10.1.1.18.$portidx' failed
with an error: $result")
if $result =~ /error/i;
if ($result =~ /^.*\"([^"]+)".*$/)
{
return $1 eq $name;
}
return 0;
}
Note: I got most of this from another Radius product (not to be mentioned
here ;-)
Steve
---
Steve Roderick ProAxis Communications, Inc.
[EMAIL PROTECTED] Internet Access Provider
(541) 757-0248
===
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
(RADIATOR) AscendSNMP
I have had no luck with the AscendSNMP NasType so I did a little research and here is the MIB that I found works: $Radius::Nas::AscendMIB.12.3.1.4.$session_id This will return the name of the user logged in with that session_id. The important thing is that it can show the user as "steve" or "[EMAIL PROTECTED]" depending on how they logged in. So I was guessing that: if ($result =~ /^.*\"([^"\@]+)["\@].*$/) would fix it. Let me know your thoughts. Steve --- Steve Roderick ProAxis Communications, Inc. [EMAIL PROTECTED] Internet Access Provider (541) 757-0248 === To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Simultaneous-Use!!!
On Thu, 25 Mar 1999, Mike McCauley wrote: > OK, due to popular demand I have added a new parameter to AuthBy. > > DefaultSimultaneousUse specifies a sim-use limit that will apply if there is no > user-specific Simultaneous-Use check item. > > Would the interested people like to download a new AuthGeneric.pm from > http://www.open.com.au/radiator/downloads/patches-2.13.1 and let me know how it > goes. You will need to remove the MaxSessions parameter from your config too. What does # Check the DefaultSimultaneousUse if we did not get a per-user # one. Warning, dont do it if we were called by a Handler the "Warning" mean? Steve --- Steve Roderick ProAxis Communications, Inc. [EMAIL PROTECTED] Internet Access Provider (541) 757-0248 === To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Simultaneous-Use!!!
On Tue, 23 Mar 1999, Mike McCauley wrote: > Im thinking of doing exactly that, but Im toying with whether or not > DefaultSessionMax (or whatever I call it) should be a Handler/realm parameter > or an AuthBy parameter? > MaxSession (for better or worse) is a Handler/Realm parameter. > > Views? At first thought it seems like a Handler/Realm parameter would make sense. What is the logic behind an AuthBy parameter? Steve === To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Simultaneous-Use!!!
On Mon, 22 Mar 1999, True Communications Corp. wrote: > defined to 1 as the default for all users in the users file. I was under the > impression > that you can override the default for any of the users by using the > Simultaneous-Use > attribute in the users file. Which is exactly what I did. Wouldn't that be nice. Unfortunately it doesn't work that way. It uses the MOST restrictive setting. I would really love to have a "DefaultSessionMax" or something. That meant without a specific Sim-Use setting use the default. Then the sim-use setting would OVERRIDE the default. Much better. :-) Steve === To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Re: Some Questions
On Tue, 23 Mar 1999, Mike McCauley wrote: > Anyone have a dictionary with the ascend vendor specific attributes (vendor > code 529) in it? I have the Ascend dictionary. > > You have received a message! > > Mon Mar 22 23:22:32 1999: ERR: Attribute number 125 (vendor 529) is not > > defined in your dictionary > > Mon Mar 22 23:22:32 1999: ERR: Attribute number 244 (vendor 529) is not > > defined in your dictionary > > Mon Mar 22 23:30:20 1999: ERR: Attribute number 32 (vendor ) is not > > defined in your dictionary > > Mon Mar 22 23:30:20 1999: ERR: Attribute number 125 (vendor 529) is not > > defined in your dictionary > > Mon Mar 22 23:30:20 1999: ERR: Attribute number 244 (vendor 529) is not > > defined in your dictionary > > Mon Mar 22 23:30:20 1999: ERR: Attribute number 120 (vendor 529) is not > > defined in your dictionary > > Mon Mar 22 23:30:20 1999: ERR: Attribute number 121 (vendor 529) is not > > defined in your dictionary > > Mon Mar 22 23:30:20 1999: ERR: Attribute number 32 (vendor ) is not > > defined in your dictionary Perhaps I am reading this wrong, but isn't it saying that it doesn't know what attribute #244 is for vendor #529? The information is in both the "standard" dictionary and the "Ascend" dictionary that are distributed with Radiator. Also there isn't anything in the Ascend dictionary that I have that isn't in the one distributed with Radiator. As a matter of fact there is more in the Radiator version. Steve === To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Radiator to MySQL
On Sun, 21 Mar 1999, Ray Brighenti wrote: > Following the instructions I went to the CPAN archive to get DBI and > found below, the instructions say 0.90 or better, 0.80 seems to be all, > is the following OK? Go to: http://www.mysql.net/download.html They have a link to download DBI 1.06. Steve --- Steve Roderick ProAxis Communications, Inc. [EMAIL PROTECTED] Internet Access Provider (541) 757-0248 === To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) Ascend dictionary
There is a typo in the dictionary.ascend file on lines 450 and 451 VALUE Framed_Protocol ATM-1483264 VALUE Framed_Protocol ATM-FR-CIR 265 should be VALUE Framed-Protocol ATM-1483264 VALUE Framed-Protocol ATM-FR-CIR 265 Note the - instead of _ Also there is no ATTRIBUTE for Ascend-Temporary-Rtes which is used on lines 895 and 896. Steve === To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) Hmmm... SQL problem
I got an error in my logfile last night which said that the query to "UPDATE" the SQL accounting database failed because: ERR: do failed for 'UPDATE ' : Lost connection to MySQL server during query Now, that doesn't seem to be a big deal, because SqlDb.pm will just reconnect to the database and try again. Of course if it can't connect it will log an error. The problem... No error logged about not being able to reconnect. AND the update didn't happen. Steve === To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Different Databases for auth and accounting
On Tue, 16 Mar 1999, Paul Gregg wrote: > Even better would be to use a different accoutning database host to > the authentication database host. This is not a problem. I am doing it now. Identifier SQLAccounting AuthSelect DBSource dbi:mysql:accountingDB:accthost.proaxis.com DBUsername radius DBAuth *** RewriteUsername s/^([^@]+).*/$1\@proaxis.com/ RewriteUsername tr/A-Z/a-z/ AcctLogFileName %L/detail-%Y-%m AuthByPolicy DoAllAuths AuthBy SQLAccounting # The following file will have a default entry which # specifies to use the "ProAxisSQLAuth" authentication defined # in a block later in this file Filename %D/users # # This block is referenced in the "users" file # it is then used to do the authentication. # Identifier ProAxisSQLAuth DBSource dbi:mysql:authDB:authhost.proaxis.com DBUsername radiusUserName DBAuth AuthSelect \ SELECT passwd,check_items,reply_items \ FROM customers \ WHERE (userid='%U') AND (status<3) AND (active=1) AND (dialup=1) EncryptedPassword AuthColumnDef 0, Encrypted-Password, check AuthColumnDef 1, GENERIC, check AuthColumnDef 2, GENERIC, reply # No accounting here AccountingTable If you wanted to you could set up additional AuthBy sections and log the accounting to multiple different servers/databases/tables. You could even split up the start and stop. Steve === To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) SQL help
On Tue, 16 Mar 1999, Mike McCauley wrote: > 5. Lons observation about not bothering to save Starts in the accounting > database is correct. Theres nothing there thats not in the Stops. That would be great if this was true, but it seems like most of the vendor stuff is only in the starts. Connect-Speed, etc. Steve --- Steve Roderick ProAxis Communications, Inc. [EMAIL PROTECTED] Internet Access Provider (541) 757-0248 === To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) SQL and EncryptedPassword
On Thu, 11 Mar 1999, Remi Godin wrote: > Hi > I'm using AuthBY SQL. > > Here's the problem: > > AuthSelect SELECT pwd FROM loginid WHERE loginid.login_id='%n' > EncryptedPassword > AuthColumnDef 0, User-Password, check Try this: EncryptedPassword AuthColumnDef 0, Encrypted-Password, check Steve === To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Two questions...
On Wed, 17 Feb 1999, Andrew wrote:
> Wed Feb 17 16:09:23 1999: ERR: do failed for 'UPDATE CallsOnline SET
> acctinputoctets = , acctoutputoctets = , acctsessiontime = ,
> acctterminatecause = 0 WHERE acctsessionid = '284842146' AND nasidentifier
> = '209.16.18.34'': ORA-00936: missing expression (DBD: error possibly near
> <*> indicator at char 42 in 'UPDATE CallsOnline SET acctinputoctets = <*>,
> acctoutputoctets = , acctsessiontime = , acctterminatecause = 0 WHERE
> acctsessionid = '284842146' AND nasidentifier = '209.16.18.34'')
[snip]
> AcctSQLStatement UPDATE CallsOnline SET acctinputoctets = \
> %{Acct-Input-Octets}, acctoutputoctets = %{Acct-Output-Octets}, \
> acctsessiontime = %{Acct-Session-Time}, acctterminatecause = \
> 0 WHERE acctsessionid = '%{Acct-Session-Id}' \
> AND nasidentifier = '%{NAS-Identifier}'
>
> First of all, does anyone know why some accounting packets are lacking
> these variables? My rather uneducated guess is that it's someone who
No, I don't know, but...
> Failing an explanation for the missing variables, does anyone have any
> suggestions on how to deal with these errors appropriately? The result of
> the error is that we end up with a start record in our CallsOnline table,
> but no stop record, so for all intents and purposes, this user is
> indefinitely logged on.
>
> Any explanations and/or ideas are greatly appreciated!
Try this:
AcctSQLStatement UPDATE CallsOnline SET acctinputoctets = \
'%{Acct-Input-Octets}', acctoutputoctets = '%{Acct-Output-Octets}',\
acctsessiontime = '%{Acct-Session-Time}', acctterminatecause = \
0 WHERE acctsessionid = '%{Acct-Session-Id}' \
AND nasidentifier = '%{NAS-Identifier}'
All I did was quote everything. SQL doesn't care if you quote numbers.
Then you just need to deal with how your SQL server will deal with = ''.
Steve
---
Steve Roderick ProAxis Communications, Inc.
[EMAIL PROTECTED] Internet Access Provider
(541) 757-0248
===
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
(RADIATOR) Kudos
On Thu, 18 Feb 1999, Mike McCauley wrote: > Apologies. > > It requires SNMP_Session-0.62.tar.gz from > ftp://ftp.switch.ch/software/sources/network/snmp/perl/ Of course after a new release, Mike gets to deal with all of the fallout. But I for one want to extend a hearty thanks and congratulations on a job well done. 2.13 is a major step forward! Thank you, Steve --- Steve Roderick ProAxis Communications, Inc. [EMAIL PROTECTED] Internet Access Provider (541) 757-0248 === To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Detail logging by Realm name
On Thu, 18 Feb 1999, Stephen Ollis wrote: > I've got multiple realms configured that authenticate via a single > flatfile. The reason for the multiple realms is due to multiple > customer types to allow them to dial in for different functions - > i.e. DVS tunnelling on BAY 5399's, IPASS, etc. I have a single > flatfile with basic authentication details, and use > RewriteUsername s/^([^@]+).*/$1/ > in each pair to strip out the realm. > > I want to have separate detail files for each realm for accounting > purpose so I setup:- > # Where do we write the accounting file > AcctLogFileName %L/detail.%R-%Y%m%d > in each realm file.. but it is creating the detail file as > %L/detail.-19990218 instead of %L/detail.realmname-19990218 > > Putting the AcctLogFileName entry before or after the Rewrite > has no effect. This is the point of my recent patch recommendation (Thanks to Mike for incorporating it into the next release!). You HAVE to stop stripping off the realm (you actually need to guarantee it is there) and then use the change that I mentioned in my previous post. This will solve your problem. Steve --- Steve Roderick ProAxis Communications, Inc. [EMAIL PROTECTED] Internet Access Provider (541) 757-0248 === To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) Easy change
I propose the following change to radiusd for the next release:
*** 87,92
--- 87,93
't', sub { $time },
'T', sub { $packet->code },
+ 'U', sub { my @n = split(/@/,
$packet->getAttrByNum($Radius::Radius::USER_NAME)); $n[0] },
'y', sub { $year%100 },
'Y', sub { $year+1900 }, # Correct Y2K behaviour for perl
);
***
*** 498,504
= localtime($time);
local $packet = $current_packet;
! $s =~ s/%([%acCdDhHLmMNnRtTyY])/&{$main::conversions{$1}}()/egs;
$s =~ s/%\{([^{]+)\}/{$packet->get_attr($1)}/egs;
return $s;
--- 499,505
= localtime($time);
local $packet = $current_packet;
! $s =~ s/%([%acCdDhHLmMNnRtTUyY])/&{$main::conversions{$1}}()/egs;
$s =~ s/%\{([^{]+)\}/{$packet->get_attr($1)}/egs;
return $s;
This is making my SQL life so much easier because I can now log the userid
and realm in separate fields.
I use the following:
RewriteUsername s/^([^@]+).*/$1\@proaxis.com/
so that I always have a realm and it is always what I expect. Then I log
all 3 %R, %U, %n and I can do report queries anyway I like. (call me
picky :-)
Steve
---
Steve Roderick ProAxis Communications, Inc.
[EMAIL PROTECTED] Internet Access Provider
(541) 757-0248
===
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
(RADIATOR) Hmmm
I have continuewhileaccept AuthSelect # Just logging The second AuthBy causes a reject. Steve === To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
