(RADIATOR) "Request from unknown client" woes

[Kitabjian, Dave]

I have a couple boxes running 2.17.1. (They're live, so I haven't upgraded
them).

When I run radpwtst from 192.168.5.18, I get messages on the server like:

NOTICE: Request from unknown client 192.168.5.18: ignored

when I clearly have:


   
Secret nodeal
DupInterval 0

IdenticalClients 192.168.5.18



in the config file. I didn't trust the HUP so I restarted radiusd. I even
tried , but that doesn't work either. I also tried leaving
off the secret on both ends (the other end is radpwtst). No dice.

What could it be barfing about?

Thanks for the help!

Dave
===
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) Framed-IP of 0.0.0.0

[Kitabjian, Dave]

Hmm. Perhaps we weren't clear. If the NAS is going to send 0.0.0.0 for any
subsequent channels of a multilink dialup (such as 2B ISDN), then you will
break all those customers if you reject them, right? Sending a "Reject" back
to the NAS isn't going to "teach it to send the right data", right?

Unless you find a way to get the NAS to give you the actual IP, you will
probably have to modify your concurrency enforcement to ignore the IP, or
something like that...

Dave

> -Original Message-
> From: William Hernandez [mailto:[EMAIL PROTECTED]] 
> Sent: Thursday, September 13, 2001 9:58 AM
> To: Radiator
> Subject: RE: (RADIATOR) Framed-IP of 0.0.0.0
> 
> 
> Thanks everyone.
> 
> Given that we don't use FramedGroupBaseAddress in our Client 
> clauses, and given that the problem has been reported with 
> Radiator out of the picture, I'll conclude that this is a NAS issue.
> 
> However, before I close this issue does it make sense to 
> write a PostAuthHook that would check FRAMEDIPADDRESS and if 
> matches 0.0.0.0 change the Accept to a Reject and basically 
> force the user to reconnect and expect (hope) the NAS will 
> generate a correct IP the second time around.
> 
> Below is a trace 4. It seems that the 0.0.0.0 address occurs 
> when Framed-Protocol=MP or Framed-Protocol=MPP. But I'll have 
> to check more cases to say for sure.
> 
> Thanks in advance,
> William
> 
> 
> Mon Aug 27 14:22:24 2001: DEBUG: Packet dump:
> *** Received from 208.249.78.9 port 1028 
> Code:   Accounting-Request
> Identifier: 18
> Authentic: 
> (<196><208><254>x<239><243><235><22>#<196>x<166><138><182><15>
> Attributes:
> User-Name = "horizonmm.com"
> NAS-IP-Address = 208.249.78.9
> NAS-Port = 10207
> Ascend-NAS-Port-Format = 3
> NAS-Port-Type = Sync
> Acct-Status-Type = Start
> Acct-Delay-Time = 0
> Acct-Session-Id = "364406391"
> Acct-Authentic = RADIUS
> Ascend-Multilink-ID = 1309213583
> Ascend-Num-In-Multilink = 2
> Acct-Link-Count = "<0><0><0>0"
> Acct-Multi-Session-Id = "4e09038f"
> Ascend-Modem-PortNo = 31
> Ascend-Modem-SlotNo = 9
> Calling-Station-Id = "7879778517"
> Called-Station-Id = "6419200"
> Framed-Protocol = MP
> 
> Mon Aug 27 14:22:24 2001: DEBUG: Check if Handler 
> Realm=surfea.net should be use d to handle this request Mon 
> Aug 27 14:22:24 2001: DEBUG: Check if Handler 
> Realm=prwebtv.net should be us ed to handle this request Mon 
> Aug 27 14:22:24 2001: DEBUG: Check if Handler 
> Realm=holaplaneta.net should b e used to handle this request 
> Mon Aug 27 14:22:24 2001: DEBUG: Check if Handler 
> Realm=prdigital.com should be used to handle this request Mon 
> Aug 27 14:22:24 2001: DEBUG: Check if Handler 
> Called-Station-Id=/5050$/ shou ld be used to handle this 
> request Mon Aug 27 14:22:24 2001: DEBUG: Check if Handler  
> should be used to handle this  request Mon Aug 27 14:22:24 
> 2001: DEBUG: Handling request with Handler '' Mon Aug 27 
> 14:22:24 2001: DEBUG: prw-sessiondb Adding session for 
> horizonmm.com,  208.249.78.9, 10207 Mon Aug 27 14:22:24 2001: 
> DEBUG: do query is: delete from RADONLINE where NASIDE 
> NTIFIER='208.249.78.9' and NASPORT=010207
> 
> Mon Aug 27 14:22:24 2001: DEBUG: do query is: insert into 
> RADONLINE (USERNAME, N ASIDENTIFIER, NASPORT, ACCTSESSIONID, 
> TIME_STAMP, FRAMEDIPADDRESS, NASPORTTYPE,
> SERVICETYPE) values ('horizonmm.com', '208.249.78.9', 010207, 
> '364406391', 99893 6544, '0.0.0.0', 'Sync', '')
> 
> Mon Aug 27 14:22:24 2001: DEBUG: Handling with 
> Radius::AuthFILE Mon Aug 27 14:22:24 2001: DEBUG: Processing 
> PostAuthHook:setSessionTimeout Mon Aug 27 14:22:24 2001: 
> DEBUG: setSessionTimeout: username is: horizonmm.com Mon Aug 
> 27 14:22:24 2001: DEBUG: setSessionTimeout: Called-Station-Id 
> is: 641920 0 Mon Aug 27 14:22:24 2001: DEBUG: Query is: 
> select USERNAME,TIMEBLOCK,CLASS,DISAB LETIME,DISABLECLASS 
> from XSTOP where USERNAME='horizonmm.com' Mon Aug 27 14:22:24 
> 2001: DEBUG: Accounting accepted Mon Aug 27 14:22:24 2001: 
> DEBUG: Packet dump:
> *** Sending to 208.249.78.9 port 1028 
> Code:   Accounting-Response
> Identifier: 18
> Authentic: 
> (<196><208><254>x<239><243><235><22>#<196>x<166><138><182><15>
> Attributes:
> 
> 
> -Original Message-
> From: Hugh Irvine [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, September 12, 2001 7:35 PM
> To: William Hernandez; Radiator
> Subject: Re: (RADIATOR) Framed-IP of 0.0.0.0
> 
> 
> 
> Hello William -
> 
> The only way to understand what is happening is to look at a 
> trace 4 debug from Radiator to see in what circumstances this 
> occurs. As it is the NAS that sends the accounting packets 
> that are used to maintain the session database, it is highly 
> likely that this is a NAS issue.
> 
> Note that we have seen similar behaviour occassionally when 
> it is Radiator allocating the addresses, and one work-around 
> is t

RE: (RADIATOR) Framed-IP of 0.0.0.0

[Kitabjian, Dave]

Exactly true for us as well, except that the NASes were Ciscos (5300s, I
think). When we were using USR/3Com gear, we didn't have this problem :-\

Dave

> -Original Message-
> From: Pascal Robert [mailto:[EMAIL PROTECTED]] 
> Sent: Wednesday, September 12, 2001 12:02 PM
> To: William Hernandez; Radiator
> Subject: Re: (RADIATOR) Framed-IP of 0.0.0.0
> 
> 
> I got this when someone connect in ISDN at two channels, the 
> second record is showing this IP.  Ascend Max TNT
> 
> > Hello everyone,
> > 
> > We're using 2.18.2. Recently we started to see FRAMEDIPADDRESS of 
> > 0.0.0.0 in RADONLINE. These records create a problem when 
> checking for 
> > Simultaneous-Use. Is this a problem with the Ascend NASes 
> that we use?
> 
> ===
> 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.
> 
===
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) return of snmpget.

[Kitabjian, Dave]

Turn on your debugging level to 4 and you'll see the entire snmpget
commandline in the logfile.

Of course, to force the command to run, you need to build up a Session DB
and have a user exceed their login limit, etc

Dave

> -Original Message-
> From: Griff Hamlin [mailto:[EMAIL PROTECTED]] 
> Sent: Thursday, August 30, 2001 2:15 PM
> To: [EMAIL PROTECTED]
> Subject: (RADIATOR) return of snmpget.
> 
> 
> Hello all,
> 
> While it is recommended to use snmpget with Radiator, it 
> appears I am going to have to use snmpinfo on AIX. What is 
> the output that Radiator is expecting to see? Also, how can I 
> find out what the exact command is that Radiator would send 
> via snmpget and can I change that (for Linux computers that 
> will use snmpget.)
> 
> Griff Hamlin, III
> 
> 
> ===
> 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.
> 
===
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) Ignore case?

[Kitabjian, Dave]

Beware. The below solution is not strictly the same as ignoring case. We had
the same problem way back.

The assumption below is that you ALSO forced your passwords in the username
database to be lower case. In our case that wasn't true; and since it wasn't
in a SQL database (it was a CDB) it was tricky getting the entries all
fixed. 

Hope this helps,

Dave
:)

> -Original Message-
> From: Hugh Irvine [mailto:[EMAIL PROTECTED]] 
> Sent: Monday, August 20, 2001 8:02 PM
> To: Todd Dokey; Radiator List
> Subject: Re: (RADIATOR) Ignore case?
> 
> 
> 
> Hello Todd -
> 
> On Tuesday 21 August 2001 04:33, Todd Dokey wrote:
> > In working up the rewrite of user names,
> > is there a way just to ignore case?
> >
> 
> You would use something like this:
> 
>   # force User-Name to all lower case
>   RewriteUsername tr/A-Z/a-z/
> 
> > I have used some of the others with success.
> >
> > PS -got the custom log messages working except that %X and 
> %Z show up 
> > literally.
> >
> 
> %X and %Z are only supported in the DateFormat parameter in 
> an AuthBy SQL.
> 
> hth
> 
> 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.
> 
===
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) attributes

[Kitabjian, Dave]

Title: Message



I 
think I noticed once that if you take the appropriate VALUE entry out of the 
Radiator dictionary, Radiator will log the number rather than the 
label...
 
Dave

  
  -Original Message-From: Sola, Carlos 
  Alberto [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 16, 
  2001 1:05 PMTo: [EMAIL PROTECTED]Subject: (RADIATOR) 
  attributes
  How can i call an attribute code instead of text value in 
  AcctSQLStatement ? 
  for example, i use %{Acct-Terminate-Cause} and i get 
  'Lost-Service' but i want a numeric code 
  Thanks 

RE: (RADIATOR) MaxSessions issue, still a problem

[Kitabjian, Dave]

Hello,

I didn't read the entire thread, but couldn't you just do this:



# strip off realm:
RewriteUsername s/^([^@]+).*/$1/



? If I neglected to read something, I apologize in advance.

Dave

> On Friday 13 July 2001 20:58, Dmitry Kopylov wrote:
> > Hello,
> >
> > and the problem here is that NAS generates the 
> Access-Request in form 
> > "username@realm", proxy stripes off the the realmname and 
> my Radiator 
> > receives just "username". Whereas the accounting request approaches 
> > the Radiator in its original form e.g. "username@realm". So the 
> > session database is built up based on the "username@realm" 
> and not on 
> > the "username". The question here is if it's possible to 
> rewrite the 
> > User-Name in Accounting request?  Or maybe there is another 
> solution?
> >
> > regards,
> > Dmitry Kopylov
===
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) changing the realm.

[Kitabjian, Dave]

I was confused about the same thing at one point.

"Realm" to Radiator is not an attribute but rather the portion of the
username following the "@". 

To work around this, we have a hook somewhat similar to yours which:

1) Strips the @realm.com off the username
2) Creates a new custom attribute, NC-Realm = realm.com
3) Then, if you need to Handle in special ways, you use .

Make sense?

Dave

> -Original Message-
> From: Griff Hamlin [mailto:[EMAIL PROTECTED]] 
> Sent: Wednesday, July 11, 2001 12:50 PM
> To: [EMAIL PROTECTED]
> Subject: (RADIATOR) changing the realm.
> 
> 
> Hello all,
> 
> I am trying to take the username (including realm or not) 
> that comes in from the packet, strip the realm and then put 
> on a new one based on the radius client that is providing the 
> packet. I have the following in a client block:
> 
> 
>RewriteUsername s/^([^@]+).*/$1/
>Secret mysecret
>PreHandlerHook sub { ${$_[0]}->change_attr('Realm','home'); \
> my $request = ${$_[0]}; \
> my $attrref = $request->{Attributes}; \
> my @attr = @$attrref; \
> foreach (@attr) { \
>my @attr2 = @$_; \
>my $attr3; \
>foreach $attr3 (@attr2) { \
>   print "attribute is '$attr3'\n"; \
>}\
> }\
>  }
> 
> 
> Mostly, what happens is I try and use the 'change_attr' 
> method to change the realm from whatever it was to 'home'. 
> However, when I tried then using a  
> block, it never noticed the new realm, and continued with the 
> old realm as per the following log file segment:
> 
> attribute is 'User-Name'
> attribute is 'hamlin'
> attribute is 'Service-Type'
> attribute is 'Framed-User'
> attribute is 'NAS-IP-Address'
> attribute is '203.63.154.1'
> attribute is 'NAS-Port'
> attribute is '1234'
> attribute is 'Called-Station-Id'
> attribute is '123456789'
> attribute is 'Calling-Station-Id'
> attribute is '987654321'
> attribute is 'NAS-Port-Type'
> attribute is 'Async'
> attribute is 'Framed-IP-Address'
> attribute is '255.255.255.254'
> attribute is 'User-Password'
> attribute is 'ϸfß5pö¼8 Ø}x'
> attribute is 'Realm'
> attribute is 'home'
> Wed Jul 11 10:45:34 2001: DEBUG: Packet dump:
> *** Received from 65.13.83.72 port 1027 
> Code:   Access-Request
> Identifier: 124
> 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
> Framed-IP-Address = 255.255.255.254
> User-Password = 
> "<207><184>f<154><223>5p<246><188>8<9><160><216>}x<153>"
> Wed Jul 11 10:45:34 2001: DEBUG: Rewrote user name to hamlin 
> Wed Jul 11 10:45:34 2001: DEBUG: Check if Handler Realm = 
> home should be used to handle this request Wed Jul 11 
> 10:45:34 2001: DEBUG: Check if Handler  should be used to 
> handle this request Wed Jul 11 10:45:34 2001: DEBUG: Handling 
> request with Handler '' Wed Jul 11 10:45:34 2001: DEBUG:  
> Deleting session for [EMAIL PROTECTED], 203.63.154.1, 1234
> 
> As you can see, when printing out attributes, it shows the 
> Realm to be 'home', and later when doing the packet dump, the 
> username is [EMAIL PROTECTED] as it was sent from the radius 
> client. Maybe this is not possible, which would be OK I have 
> other ideas to work around it. But now I'm curious.
> 
> Griff Hamlin, 
> 
> 
> ===
> 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.
> 
===
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) Simultaneous Use Problems

[Kitabjian, Dave]

I didn't know PM3's supported SNMP. You might want to find out whether SNMP
or Finger works with your equipment. If SNMP, you might want to specify an
SNMPCommunity entry for the .

Also, look in /var/log/radiator/radius.log and it will show you what
Radiator tries to do when it should be enforcing sim use. In the case of
SNMP, I know it will show you the whole Unix commanline that it runs, which
you can copy and paste onto your command line to test directly.

Also, if you're not sure what's in your SessionDatabase, you might want to
use a SessionDatabase DBM and then use the cgi to see who RADIATOR thinks is
online.

Dave

> -Original Message-
> From: Jonathon Lindbo [mailto:[EMAIL PROTECTED]] 
> Sent: Friday, July 06, 2001 12:34 PM
> To: [EMAIL PROTECTED]
> Subject: (RADIATOR) Simultaneous Use Problems
> 
> 
> Hi,
> 
> I have been trying for the past 4 days to get my Simultaneous Login 
> restrictions to work.  I am currently working with PM3's and 
> have SNMP 
> enabled on them all.  I'm not sure what I am doing wrong.  
> Below is the 
> config that I am using.  Any ideas ?  Where should I look for 
> debugging 
> information on this.  I am not seeing much in the radius.log.
> 
> Thanks
> Jon Lindbo
> 
> 
> ### BASE CONFIGURATION ###
> Trace   5
> PidFile /tmp/radiusd.pid
> AuthPort1645
> AcctPort1646
> LogDir  /var/log/radiator
> DbDir   /etc/radiator/raddb
> LogFile %L/radius.log
> SnmpgetProg /usr/local/bin/snmpget
> FingerProg  /usr/bin/finger
> #LivingstonOffs 23
> #LivingstonHole 1
> LivingstonHole  0
> 
> ### CLIENT CONFIGURATION ###
> 
>  Secret BBsecretKEY
>  DupInterval 2
>  NasType Livingston
> 
> 
> ### REALM CONFIGURATION ###
> 
> 
>  RewriteUsername s/^([^@]+).*/$1/
>  AcctLogFileName %L/%Ndetail
>  AcctLogFileFormat %{Timestamp} %{Acct-Session-Id} 
> %{User-Name}
>  PasswordLogFileName %L/password.log
>  MaxSessions 1
>  
>  Identifier System
>  Filename /etc/shadow
>  Match ^([^:]*):([^:]*):?[^:]*:?([^:]*)
>  DefaultSimultaneousUse 1
>  AddToReply Service-Type = Framed-User, 
> Framed-Protocol = PPP, Session-Timeout = 14400, Idle-Timeout = 1500
>  
> 
> 
> 
> ===
> 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.
> 
===
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) hangs

[Kitabjian, Dave]

OpenLDAP does not react very nicely to garbled data in Usernames; in fact,
it hangs. And it can even hang Radiator, even though I don't exactly
understand how that interaction between Radiator and the LDAP server works.

The solution for us was to use a RewriteUsername to throw out characters in
the Username except for ones we're expecting. Sometimes binary junk comes in
as the Username from noisy phone lines, and that will filter out the junk. A
similar solution is to use an early Handler to REJECT any authentication
requests with garbled characters in the username.

Dave

> From: "Chris van Meerendonk" <[EMAIL PROTECTED]>
> 
> Hello,
> 
> We have a problem with radiator in combination with Nortel 
> CVX's. = Sometimes (once or twice a week) the radius server 
> hangs. In that case = we have to give it a kill -9 and start 
> it again. The logs doesn't show = any thing. Is this a known issue?
> 
> Our Radiator (problem occurs from a least 2.16.3 - 2.18.2) 
> runs on linux = in combination with LDAP.
===
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) Working with Cisco IVR

[Kitabjian, Dave]

Title: Message



Hmm. I 
don't think there was anything too complicated about setting up the Gateway to 
do the IVR part. But I didn't do that part :) I handled the Radius part. That 
was a little tricky. For the IVR script that we chose on the Gateway, it works 
like this:
 

  1. 
  Phone call comes in
  2. 
  Before the IVR says ANYTHING, the IVR does PRE-authentication to RADIUS, using 
  User-Name =  and Password = "".
  3. 
  If that authentication passes, then the IVR asks for the destination number 
  and the call is placed. But if the authentication fails, the IVR asks for the 
  Account# and PIN, and then does the SECOND RADIUS authentication, using 
  User-Name =  and Password = . Assuming the second 
  one passes, then the call is placed. 
 
To 
handle both cases, we put the following hook in the main  
clause:
 
    # Get the 
decoded password from the input packet and add an 
attribute    # to the input packet if 
it is blank. Set the decoded password 
equal    # to the user name 
attribute.    PreHandlerHook sub {if 
(${$_[0]}->decodedPassword() eq '') 
\    
{${$_[0]}->add_attr('ANI-No-Pass', 'true'); 
\    
${$_[0]}->{DecodedPassword} 
=${$_[0]}->get_attr('User-Name');}}
 
and 
then we use two Handlers for the two different cases:
 

  # 
  Handler for BLANK password  
   
      AuthBy 
  LDAP_AUTH_NO_PASSWORD
   
  
   
  # 
  Handler for "catch-all"    
  
   
      AuthBy 
  LDAP_AUTH
  
Then, 
in LDAP_AUTH AuthBy we have:
 
    
UsernameAttr 
uid    
PasswordAttr  pass 
 
whereas in the LDAP_AUTH_NO_PASSWORD AuthBy we 
use:
 
    
UsernameAttr uid 
    
PasswordAttr    uid 
 
It 
works quite nicely. If there's a smoother solution, I'd love to know of 
it!
 
Dave

  
  -Original Message-From: J. Esteban Saa 
  Barona. [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 28, 2001 
  1:37 PMTo: [EMAIL PROTECTED]Subject: prepaid calling 
  cards with Cisco
  Hi Dave,
   
  I'm triying to do prepaid calling cards 
  using Cisco Gateways, we have many 1750 and I don't know how to make them do 
  Interactive Voice Responce and check input against a DB. Can you please point 
  me in the  right direction ?
   
  You may want to check my website I 
  developed I Call Detail Recorder for Cisco Gateways. Usefull for postpaid and 
  QOS Reports.
   
  Thank you in advance,
   
  Esteban
  newagetelco.com

RE: (RADIATOR) Session Database

[Kitabjian, Dave]

Hey.

1) Have you tested INSERTing to your DB from the command line to make sure
it's working? Perhaps from a Perl command line?

2) Put "Trace  4" in your config file, restart Radiator, try again, and then
let us know what shows up in your logfile. I'd like to know if it's even
TRYING to do the INSERT...

Dave

> -Original Message-
> From: Kyle [mailto:[EMAIL PROTECTED]] 
> Sent: Thursday, June 28, 2001 5:51 AM
> To: [EMAIL PROTECTED]
> Subject: (RADIATOR) Session Database
> 
> 
> I've got this directive in my . However, when 
> an user logs onto the system, and is authenticated by 
> Radiator, it fails to put an entry into the session table. 
> What am I doing wrong? Radiator-2.18.2 with RH-7.0 and mySql-3.23.38.
> 
> 
> 
>   ## Set the database Identifier
>   Identifier SDB1
> 
>   ## Set the database source
>   DBSource  dbi:mysql:**
>   DBUsername**
>   DBAuth**
> 
>   AddQuery insert into RADONLINE (USERNAME, \
>   NASIDENTIFIER, NASPORT, \
>   ACCTSESSIONID, TIME_STAMP, FRAMEDADDRESS, PORTTYPE, \
>   SERVICETYPE) values ('%n','%N',%{NAS-Port}, \
>   '%{Acct-Session-Id}', %{Timestamp}, \
>   '%{Framed-Address}','%{Port-Type}','%{Service-Type}')
> 
>   DeleteQuery delete from RADONLINE where USERNAME='%n' and \
>   NASIDENTIFIER='%N' and NASPORT=%{NAS-Port}
> 
>   ClearNasQuery delete from RADONLINE where NASIDENTIFIER="%N'
>   CountQuery select NASIDENTIFIER,NASPORT,ACCTSESSIONID from \
>   RADONLINE where USERNAME='%n'
> 
> 
> ===
> 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.
> 
===
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) Newbie question: Radiator setup and config

[Kitabjian, Dave]

Put

Trace  4

in your config file and then restart Radiator. You'll probably get some
really useful logging information!

Dave

> -Original Message-
> From: Stephen Caporossi [mailto:[EMAIL PROTECTED]] 
> Sent: Monday, June 25, 2001 4:12 PM
> To: [EMAIL PROTECTED]
> Subject: (RADIATOR) Newbie question: Radiator setup and config
> 
> 
> I am in the process of "evaluating" Radiator as well as 
> setting up my first radius server, and have a few questions 
> about verifying the system is working properly/configuring it 
> to authenticate to /etc/shadow.  
> 
> I am running RHLinux 7.1 and Radiator 2.18.2.  It appears 
> that the install went OK and when I run radpwtst, without any 
> arguments, it works fine.  However, after configuring radius.cfg 
> to authenticate to /etc/shadow and/or to the users flat file, 
> it returns 
> 
> Sending Access-Request...
> Rejected: Request Denied
> 
> radpwtst -user  -password 
> 
> In the logfile, it tells me 
> Access rejected for :No such user
> 
> the accounting works OK
> 
> I added the user and password to the /usr/local/etc/users 
> file and the account also is created on the Linux box.  Any 
> ideas and or suggestions would be appreciated.
> 
> Thanks, Steve
> ===
> 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.
> 
===
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 Authentication Failures ... file descriptors breaking?

[Kitabjian, Dave]

Title: Message



 

  
  The sheer volume of turning on tracelevel 
  4,  
Two question for 
starters:
 
1) What 
AuthBy modules are you using?
 
2) You have 
to turn on DEBUG logging! You should be able to manage the logs using 
"newsyslog", a utility that comes with FreeBSD, or else try "multilog" by 
Bernstein:
 
    http://cr.yp.to/daemontools/multilog.html
 
Then show 
us what comes up in your logfile...
 
Dave
:)

RE: (RADIATOR) I need to change the symbol that is used to seperate username and realm.

[Kitabjian, Dave]

I don't know how easy it is to change the definition of "realm", so I'll
defer that answer to someone else.

However, you can set aside the  feature and use the  feature
along with a Perl regexp to look for whatever character you want as the
delimiter.

Dave
:)

> -Original Message-
> From: Felicetti, Stephen A. [mailto:[EMAIL PROTECTED]] 
> Sent: Wednesday, June 20, 2001 3:24 PM
> To: '[EMAIL PROTECTED]'
> Subject: (RADIATOR) I need to change the symbol that is used 
> to seperate username and realm.
> 
> 
> I'm using 2.16.1 on Solaris.
> I have 2 realms in my config file.
> One is the default of no realm, and the other is used to 
> handle my firewall
> authentications: 
> It works nicely when I use: username@firewall for most 
> authentications. However, the problem I'm running into, is in 
> order for my firewall to authenticate FTP sessions, it uses a 
> goofy syntax in the form of:
> 
> ftp-account-name@[EMAIL PROTECTED]
> 
> See all those @ symbols? The firewall uses them as field 
> delimiters, so I can't use the old username format of 
> username@firewall. If I can get Radiator to use a different 
> symbol other then @ to determine the realm, it would make 
> life a whole lot easier. Modifying the firewall isn't an option.
> 
> Is this possible?
> 
> Thanks a lot!!
> Steve
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Stephen A. Felicetti  Fox Chase Cancer Center
> Sr. Network Engineer  215-728-2956  (v)
> Research Information Technology Facility  215-728-2513 (f)
> [EMAIL PROTECTED] 
> 
> 
> 
> 
===
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) SimultaneousUse using internal session database

[Kitabjian, Dave]

> P.S. I think it would be very helpful if you included an 
> option for case
> insensitivity for the internal session database in a future 
> version of RADIATOR

You're on the right track. What it needs to store is two things:

- the ORIGINAL name as coming from the NAS. That will allow us to make sure
we SNMP get the exact name. 

- the REWRITTEN name which should match what is stored in our user database.
That will allow us to have a single entity to COUNT in the Session DB to
enforce concurrency limits against. 

It would be nice if support for this were part of the standard Radiator
configs.

Dave
===
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) Safe to to AcctLogFileName?

[Kitabjian, Dave]

We want to add some "Accounting" records of our own to log, for example,
when and why users are rejected access. Because we already have a
sophisticated system in place for collecting accounting data, parsing it,
and making it available to our TSR's via VB, we want to use the same channel
to collecting this new data. 

Using  and a custom FailureFormat including %r, %0 and %1,
this works very nicely :) The question is...

Is it safe to write to the same file as AcctLogFileName? I guess another way
of asking is, is the AuthLog FILE write operation atomic? 

The reason I'm concerned is because now, for the first time, I'll have two
processes accessing that file at once; and since our Authentication and
Accounting are handled by separate Radiators, and the AuthLog is used by
Authentication and the AcctLogFileName is used by Accounting, corruption
could occur.

Thanks in advance!

Dave 
NetCarrier, Software Engineering

===
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) how to speed up "snmpget"?

[Kitabjian, Dave]

One problem that may inhibit our rollout of concurrency enforcement is the
slowness of "snmpget" to query the NASes. Chatting with others and checking
the archive, it appears that others have had this problem, and that OSC has
indicated they may use Net::SNMP instead of snmpget: 

http://www.mail-archive.com/radiator@open.com.au/msg05815.html

So my questions are,

1) short of waiting for Net::SNMP, are there any suggestions about how to
speed up the snmpget query?

2) Hugh, does your affirmation of Net::SNMP mean that you expect it to solve
the performance problem with snmpget? (I have no idea how fast Net::SNMP is)

As always, thanks! 

Dave 
NetCarrier, Software Engineering

===
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) duplicate entries on radonline

[Kitabjian, Dave]

I think what you want is actually called "DefaultSimultaneousUse":

http://www.open.com.au/radiator/ref.html#pgfId=399936

Also, don't forget the NasType and SNMPCommunity (if applicable) in your
 clauses:

http://www.open.com.au/radiator/ref.html#pgfId=363701

Dave 
NetCarrier, Software Engineering


> -Original Message-
> From: Anton Krall [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, May 30, 2001 8:34 AM
> To: [EMAIL PROTECTED]
> Subject: (RADIATOR) duplicate entries on radonline
> 
> 
>   Guys.. I just noticed something like this on my radonline.cgi
> 
> 
>   [EMAIL PROTECTED] 154.17.32.21 2081 
> 331525582 Tue May 29 19:24:06 2001 0 04:09:03 200.53.13.192 Async 
> delete session 
>   [EMAIL PROTECTED] 154.17.32.23 2127 
> 339007517 Tue May 29 15:07:49 2001 0 08:25:20 200.53.17.205 Async 
> delete session 
>   jfares 154.17.32.25 2257 340731517 Sat May 26 07:51:15 
> 2001 3 15:41:54 200.53.21.117 Async  delete session 
>   jfonseca 154.17.32.22 1025 336815432 Tue May 29 
> 22:58:37 2001 0 00:34:32 200.53.15.180 Async  delete session 
>   jgalvez 154.17.32.25 1206 340755963 Wed May 30 00:05:23 
> 2001 0 00:28:46 200.53.21.218 Async  delete session 
>   [EMAIL PROTECTED] 154.17.32.20 1137 317368549 Wed 
> May 30 00:23:21 2001 0 00:10:48 200.53.11.86 Async  delete
> session 
>   [EMAIL PROTECTED] 154.17.32.21 1055 331527565 Wed 
> May 30 00:26:20 2001 0 00:07:49 200.53.13.203 Async  delete
> session 
>   [EMAIL PROTECTED] 154.17.32.25 1096 340755951 Wed 
> May 30 00:02:19 2001 0 00:31:50 200.53.21.198 Async  delete
> session 
>   jjlobo 154.17.32.26 1196 317004407 Tue May 29 23:23:53 
> 2001 0 00:09:16 200.53.41.187 Async  delete session 
> 
> 
>   2 users are connected twice...
> 
>   How  can  I limit this... I tried using the SimultaneousUse 1 on
>   the  Authby but it didnt seem to work.. any ideas? anybody using
>   it and working cause Im almost sure I did something wrong.
> 
> Saludos
> 
> Anton Krall
> 
> 
> ===
> 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.
> 
===
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) default realms

[Kitabjian, Dave]

Ahh.

In this case, you have a single default handler:



AuthByPolicy  ContinueWhileReject


Identifier  GRIC
...



Identifier  USOnline
...



Something like that.

Dave

> -Original Message-
> From: Cory Visi [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, May 23, 2001 11:59 AM
> To: Kitabjian, Dave
> Cc: [EMAIL PROTECTED]
> Subject: Re: (RADIATOR) default realms
> 
> 
> I would like the requests to be handled in this fashion:
> 
> Suppose a user logs in with your example, "[EMAIL PROTECTED]".
> First the realm is checked against any local Realm/Handler statements.
> Then the first DEFAULT realm statement catches it and proxies 
> it to a GRIC
> radius server. 
> Finally, the second DEFAULT realm (hypothetically) statement 
> catches it
> and proxies it to a USOnline radius server.
> If all of these fail, the radius request fails.
> 
> In this setup USOnline requests could be pretty slow to 
> repond, but that's
> ok, since GRIC is more expensive to our end-user.
> 
> Thanks,
> Cory
> 
> Kitabjian, Dave [[EMAIL PROTECTED]] wrote:
> > Hmm. Well, my question to you is, whom to you WANT to get 
> the default
> > realms? In other words, say you get a request from 
> "[EMAIL PROTECTED]" --
> > whom are you going to proxy it to: GRIC or USOnline?
> > 
> > After you answer that question, we can answer your question.
> > 
> > Dave
> > 
> > > -Original Message-
> > > From: Cory Visi [mailto:[EMAIL PROTECTED]]
> > > Sent: Tuesday, May 22, 2001 11:26 AM
> > > To: [EMAIL PROTECTED]
> > > Subject: (RADIATOR) default realms
> > > 
> > > 
> > > I'm currently attempting to implement both GRIC and 
> USOnline roaming
> > > setups. Both of these require me to use a default realm. As 
> > > far as I can
> > > tell, Radiator only supports one default realm. Is this 
> > > correct? If not,
> > > how do I get Radiator to recognize two or more entries for a 
> > > default realm
> > > (currently it seems to use the last definition).
> 
===
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) Trouble with accounting detail file

[Kitabjian, Dave]

It 
could help if you post a sample section of your detail file.
 
Also, 
for this type of stuff, rule out NAS problems by just testing with radpwtst, 
probably with the [-accton] or [-acctoff] options. Then post the results back to 
this list.
 
Dave

  -Original Message-From: Nihal 
  [mailto:[EMAIL PROTECTED]]Sent: Tuesday, May 22, 2001 3:57 
  PMTo: [EMAIL PROTECTED]Subject: (RADIATOR) Trouble 
  with accounting detail file
  I'm having trouble getting Radiator to log to the 
  detail file. Monitoring the
  accounting requests on the NAS I can see that its 
  sending the proper information.
  However I seem to get rare and sporadic entries 
  in the detail file.
   
  My ultimate goal here is to get the 
  simultaneous-use limit to work, and I read
  somewhere that it needed accounting requests to 
  keep track.
   
  Anyone have any suggestions on what might be the 
  problem?

RE: (RADIATOR) default realms

[Kitabjian, Dave]

Hmm. Well, my question to you is, whom to you WANT to get the default
realms? In other words, say you get a request from "[EMAIL PROTECTED]" --
whom are you going to proxy it to: GRIC or USOnline?

After you answer that question, we can answer your question.

Dave

> -Original Message-
> From: Cory Visi [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, May 22, 2001 11:26 AM
> To: [EMAIL PROTECTED]
> Subject: (RADIATOR) default realms
> 
> 
> I'm currently attempting to implement both GRIC and USOnline roaming
> setups. Both of these require me to use a default realm. As 
> far as I can
> tell, Radiator only supports one default realm. Is this 
> correct? If not,
> how do I get Radiator to recognize two or more entries for a 
> default realm
> (currently it seems to use the last definition).
> 
> Thanks,
> 
> -- 
> Cory Visi
> DiscoverNet, Inc.
> 111 Prospect Street
> Stamford, CT 06902
> (203) 351-1178
> ===
> 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.
> 
===
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) Radiator with Authby NT

[Kitabjian, Dave]

Hmm, I'm confused.

> i have the problem that radiator will authenticate telnet but 
> not dialup 
> access to a cisco 3620 i get the error message

This part makes it sound like your 3620 isn't configured right. Did you test
both telnet and dialup using the same login name?

> Access rejected for Blah: NT CheckPassword failed: 87: The 
> parameter is 
> incorrect.

This part makes it sound like you have a problem in your Radiator
configuration w.r.t. how it talks to NT...

Dave
===
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) Simultaneous Dialup question

[Kitabjian, Dave]

Use:

NasType   unknown

for all such Nases. Then, Radiator will trust the SessionDatabase. If you
just want to not enforce simultaneous use for a Nas, use:

NasType   ignore

Then you're set!

Dave

> Hello all,
> 
> I believe that Radiator uses SNMP to querry routers and determine
> whether or not a user that is currently dialed up and in the database
> (the session database, in this case and SQL database) really is logged
> in or not. At least, this is my understanding and my log files seem to
> confirm it. The problem is, some of our customers use routers that we
> cannot get to by SNMP or any other means, and we have to just 
> trust the
> session database 
===
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) Telstra DailConnect; AuthBy LDAP2?

[Kitabjian, Dave]

> Lastly, in the case of proxying RADIUS accounting, is there anything
> particularly clever required to log to file and proxy to 
> another RADIUS
> server which may or may not be always available (i.e. ignore
> unreachability problems)?

For this, you might benefit from options such as

AcctFailedLogFileName / AcctLogFileFormat
http://www.open.com.au/radiator/ref.html#pgfId=291004

and also

AccountingHandled
http://www.open.com.au/radiator/ref.html#pgfId=363868

Dave

===
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) best technique to fallback to flat file if DB server not available

[Kitabjian, Dave]

I'm not a whiz at using DEFAULT, but you might benefit from:

13.2.6 Fall-Through
This attribute is not actually returned to the NAS. Its presence causes
Radiator to continue looking for a match with the next DEFAULT user name.

Fall-Through = yes

http://www.open.com.au/radiator/ref.html#pgfId=330995

Dave

> -Original Message-
> From: John Coy [mailto:[EMAIL PROTECTED]]
> Sent: Friday, April 27, 2001 11:31 AM
> To: [EMAIL PROTECTED]
> Subject: Re: (RADIATOR) best technique to fallback to flat file if DB
> server not available
> 
> 
> I know it's wierd to reply to my own message, but I found
> something in the RADIATOR archives:
> 
> [ From Mike McCauley ]
> 2. Chain a second authentication method after SQL, so that if 
> SQL fails (and
> says IGNORE), it will then auth from (say) a local flat file:
> 
> 
>  AuthByPolicy ContinueWhileIgnore
>  
>  # whatever
>  
>  # If SQL fails, auth from flat file:
>  
>  Filename whatever
>  
> 
> 
> However, this technique doesn't work if you have an arrangement
> similar to this one -- here, my default realm is authenticated
> using .  Inside that file, I make references to
> several authentication methods, including  and
> .  However, since the  fails, it
> never gets to move on to the second DEFAULT.  Not sure if this
> is intended to be this way, or if my config is just so messed
> up... anyhow, if there's a way to get it to move on to the next
> DEFAULT entry that's what I'd like to do
> 
> My radiusd.cfg (excerpts):
> 
> -- radiusd.cfg --
> 
>  RewriteUsername tr/A-Z/a-z/
>  AuthByPolicyContinueWhileIgnore
> 
>  AuthBy  AuthANCIUsers
> 
> 
> 
>  Identifier  AuthANCIUsers
>  Filename%D/users
> 
> 
> 
>  Identifier  AuthSQLPasswd
> 
>  DBSourcedbi:Oracle:starship
>  DBUsername  uname
>  DBAuth  password
> 
>  AuthSelect  SELECT password, checkattr, replyattr \
>  FROM   passwd \
>  WHERE  username = LOWER('%n')
> 
>  AuthColumnDef   0, Encrypted-Password, check
>  AuthColumnDef   1, GENERIC, check
>  AuthColumnDef   2, GENERIC, reply
> 
>  AddToReplyIfNotExistAscend-Maximum-Channels = 1
> 
>  AccountingTable
> 
> 
> 
>  Identifier  UNIX
>  Filename/usr/local/etc/shadow
>  GroupFilename   /usr/local/etc/group
> 
>  AddToReplyIfNotExistAscend-Maximum-Channels = 1
> 
> -- end radiusd.cfg --
> 
> Then, inside the "users" file, you have a DEFAULT entry:
> 
> -- users --
> DEFAULT Auth-Type = AuthSQLPasswd
>  Ascend-Idle-Limit = 1800,
>  Ascend-Assign-IP-Pool = 0,
>  User-Service = Framed-User,
>  Framed-Protocol = PPP,
>  Ascend-Maximum-Call-Duration = 480,
>  Ascend-Client-Primary-DNS = 208.133.27.10,
>  Ascend-Client-Secondary-DNS = 216.152.26.168,
>  Ascend-Client-Assign-DNS = DNS-Assign-Yes,
>  Ascend-Shared-Profile-Enable = 0,
>  Ascend-Multicast-Client = 1,
>  Ascend-Multicast-Rate-Limit = 5
> 
> DEFAULT Auth-Type = UNIX
>  Ascend-Idle-Limit = 1800,
>  Ascend-Assign-IP-Pool = 0,
>  User-Service = Framed-User,
>  Framed-Protocol = PPP,
>  Ascend-Maximum-Call-Duration = 480,
>  Ascend-Client-Primary-DNS = 208.133.27.10,
>  Ascend-Client-Secondary-DNS = 216.152.26.168,
>  Ascend-Client-Assign-DNS = DNS-Assign-Yes,
>  Ascend-Shared-Profile-Enable = 0,
>  Ascend-Multicast-Client = 1,
>  Ascend-Multicast-Rate-Limit = 5
> -- end users --
> 
> At 09:02 PM 4/26/01 -0500, you wrote:
> >What's the best technique to have Radiator fall back to 
> authentication
> >via flat file (UNIX-style auth for example) instead of SQL 
> database if the
> >SQL database isn't available.
> >
> >I tried using two DEFAULT entries in my users file, one which did SQL
> >auth, the other which did UNIX auth but that didn't work.  
> Instead, it
> >fails to connect to the DB server and won't move on to the flat file.
> >
> >Hints, tips welcome.
> >
> >John
> >
> >
> >===
> >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.
> 
> 
> ===
> 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.
> 

===
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) DefaultReply and AddToReply

[Kitabjian, Dave]

Try:



...
AuthBy CATCHALL_REJECT
RejectHasReason


#


Identifier CATCHALL_REJECT
Filename %D/users.reject


#

In users.reject:

DEFAULT Auth-Type = "Reject:Your Username is completely garbled; you may
have a
noisy phone line."

Does that help?

Dave

> -Original Message-
> From: Pascal Robert [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, April 24, 2001 9:16 AM
> To: [EMAIL PROTECTED]
> Subject: (RADIATOR) DefaultReply and AddToReply
> 
> 
> Hi,
> 
> I'm working with a demo with Radiator and I have a "small" problem.
> 
> One of our wholesalers want some more attributes in the 
> reply.  So I used
> AddToReply to add them to the Accept-Request answer, but I 
> also need to send
> some generic attributes if the request has failed (bad 
> username or password,
> etc.).
> 
> I tried with a DefaultReply but when the request is rejected, 
> the attributes
> are not sending back to the proxy server.
> 
> Realm config:
> 
> 
> RewriteUsername s/^([^@]+).*/$1/
> RejectHasReason
> 
> Filename ./users
> AddToReplyIfNotExist User-Name = 1, User-Password = 1,
> User-Service = Framed-User, Ascend-Assign-IP-Pool= 0, 
> Ascend-Idle-Limit =
> 1200, Proxy-State = 1
> DefaultReply User-Name = 0, User-Password = 
> 0, User-Service
> = Framed-User, Ascend-Assign-IP-Pool= 0, Ascend-Idle-Limit = 1200,
> Proxy-State = 1
> NoDefault
> 
> # Log accounting to the detail file in LogDir
> AcctLogFileName ./detail
> 
> 
> The only attribute that is sent back is:
> 
> *** Sending to 127.0.0.1 port 49259 
> Code:   Access-Reject
> Identifier: 221
> Authentic:  1234567890123456
> Attributes:
> Reply-Message = "Bad Password"
> 
> -- 
> +--+
> | Pascal Robert   Inter.net Canada |
> |  |
> | Gestionnaire technique de projets /Technical Project Manager |
> |  |
> | [EMAIL PROTECTED]  |
> +--+
> 
> 
> 
> ===
> 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.
> 

===
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) Controlling session: DBM file

[Kitabjian, Dave]

I'm not an expert, but based on my experience I don't think checking the DBM
is your problem. I'm more inclined to think that, after it checks the DBM,
it's doing an snmpget and that's what's taking the time.

Do you have a NasType specified in any of your  clauses? Also, after
you see the delay, grep your (DEBUG 4) logfile for "snmpget"...

Dave

> -Original Message-
> From: Hugo Dias [mailto:[EMAIL PROTECTED]]
> Sent: Monday, April 23, 2001 10:01 PM
> To: Radiator Mailing
> Subject: (RADIATOR) Controlling session: DBM file
> 
> 
> Hugh,
> 
> I am trying to use MaxSession and SessionDatabase together but the
> radiator seens to be very low and stop to answer. I think its 
> happening
> because  the radiator has to check the DBM all the time. 
> Could you help on
> this? I am seending a part of my configuration:
> 
>  DBFILE-psinet.com.br >
> AuthBy CheckDBpsinet
> AcctLogFileName %L/../acct/psinet.com.br-%Y%m%d%H
> SessionDatabase psinet.1
> #MaxSessions1
> 
> 
>  DBFILE-horizontes.com.br >
> AuthBy CheckDBhorizontes
> AcctLogFileName %L/../acct/horizontes.com.br-%Y%m%d%H
> SessionDatabase inter.net.1
> #MaxSessions1
> 
> 
> 
> 
> AuthByPolicy ContinueUntilAccept
> AuthBy CheckDBpsinet
> 
> AuthBy CheckDBhorizontes
> 
> 
> PostAuthHook file:"%D/scripts/post-auth.pl"
> 
> 
> Thanks
> Hugo José C.C. Dias
> PSINet - Salvador
> System Administrator Manager - Latam
> 55 71 340-3301
> [EMAIL PROTECTED]
> Visite www.psinet.com.br - PSINet "The Internet Super Carrier"
> 
> - Original Message -
> From: "Hugh Irvine" <[EMAIL PROTECTED]>
> To: "Andy De Petter" <[EMAIL PROTECTED]>; "Radiator Mailing"
> <[EMAIL PROTECTED]>
> Sent: Monday, April 23, 2001 8:43 PM
> Subject: Re: (RADIATOR) howto (CHAP-Password)
> 
> 
> >
> > Hello Andy -
> >
> > You are out of luck I am afraid - when CHAP is used, you must have
> > the plaintext password in your database, because only the 
> encryptions
> > are compared.
> >
> > hth
> >
> > Hugh
> >
> >
> > At 11:17 +0200 01/4/23, Andy De Petter wrote:
> > >Is there a variable, that contains the plaintext (decrypted)
> CHAP-Password,
> > >for authentication packets?  I want to log the username 
> and cleartext
> > >password, for all users that are authenticating.. also the 
> ones, with
> > >CHAP-Password..
> > >
> > >thx,
> > >
> > >-a
> > >
> > >
> > >--
> > >"For nothing can seem foul to those that win."
> > >   - Henry IV, Pt1, Act 5, Sc 1
> > >
> > >*** DISCLAIMER ***
> > >This e-mail and any attachments thereto may contain 
> information, which
> > >is confidential and/or protected by intellectual property 
> rights and
> > >are intended for the sole use of the recipient(s) named 
> above. Any use
> > >of the information contained herein (including, but not limited to,
> > >total or partial reproduction, communication or distribution in any
> > >form) by persons other than the designated recipient(s) is 
> prohibited.
> > >If you have received this e-mail in error, please notify the sender
> > >either by telephone or by e-mail and delete the material from any
> > >computer. Thank you for your cooperation.
> > >
> > >
> > >===
> > >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.
> >
> > --
> >
> > NB: I am travelling this week, so there may be delays in our
> correspondence.
> >
> > Radiator: the most portable, flexible and configurable RADIUS server
> > anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
> > Platypus, Freeside, Interbiller, TACACS+, PAM, external, etc, etc.
> > Available on Unix, Linux, FreeBSD, Windows 95/98/2000, NT, MacOS X.
> >
> > ===
> > 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.
> >
> 
> 
> ===
> 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.
> 

===
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.

(RADIATOR) Tip: AuthBy GROUP with 2 RADIUS auths

[Kitabjian, Dave]

This tip is just for the archive and fyi, in the hopes that it might help
someone out.

You can get confusing results when using a configuration similar to the
following:



AuthByPolicyContinueWhileReject


...


...




The AuthByPolicy docs say that each Auth will be tried in turn, according to
the Policy specified. The problem is that Radiator handles AuthBy RADIUS
differently than it does other AuthBys: it doesn't wait for the reply from
the proxy before moving on. 

What we wanted was to proxy to one provider, and if they are rejected there,
try the other provider (we just acquired another ISP with a separate
authentication pool, etc). So what happened to us was that we got crazy,
intermingled results, like:

Code:   Access-Accept
Identifier: 136
Authentic:  1234567890123456
Attributes:
Reply-Message = "Request Denied"
Service-Type = Framed-User
Framed-Protocol = PPP
Idle-Timeout = 1200

Crazy!

So anyway, the solution is to put to Synchronous flag in the first AuthBy
RADIUS, such as:



AuthByPolicyContinueWhileReject


Synchronous
...


...




That does wonders.

Dave
:)

===
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.

(RADIATOR) bug?: AuthLog not picked up by HUP

[Kitabjian, Dave]

I have 2.18 + all patches running. Config section attached.

I added the AuthLog parameter and the  section, and they
weren't picked up until after restarting radiusd (completely).

I know folks mentioned this earlier, but I thought that the reloading of
Handlers was fixed with 2.18, so I thought I would mention this.

Dave

p.s. Installing 2.18 "on top of" the pre-existing 2.16 shouldn't have been a
problem, should it?

#


Identifier  davesauthlogger
Filename%L/authlog
LogSuccess  1
LogFailure  1
FailureFormat   %l:%U:%P:%0:%1


#
#


AuthLog davesauthlogger
SessionDatabase SDB1
AuthBy  FLATFILE_AUTH
AcctLogFileName %D/Accounting/daveppp-%h


#

===
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) Re: Returning avpairs with a an Access-Reject?

[Kitabjian, Dave]

Actually, I'd love to see the whole(?) API which is available to us in Hooks
documented in an appendix to the venerable "manual" :) A few are mentioned
throughout already, like get_attr(). But for most you have to look through
the source.

Dave
:O

> -Original Message-
> From: Simon Hackett [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, April 18, 2001 11:12 AM
> To: [EMAIL PROTECTED]
> Subject: (RADIATOR) Re: Returning avpairs with a an Access-Reject?
> 
> 
> To follow up my own posting... I found one way that works, a 
> PostAuthHook:
> 
> # drop an h323 return code of 1 (auth failed) into the reply if it is
> # an access reject or reject_immediate - SWH hack for debitcard script
> 
> PostAuthHook sub { ${$_[1]}->add_attr('cisco-h323-return-code', \
>  'h323-return-code=1') \
>if (${$_[2]} 
> == $main::REJECT) \
>  || (${$_[2]} == 
> $main::REJECT_IMMEDIATE)}
> 
> Which gets the job done, but I don't see why attributes generated as 
> part of a reject shouldn't wind up in the return packet. Maybe it's 
> how I'm rejecting the user (a DEFAULT entry in a users file which 
> says 'Auth-Type = Reject')?
> 
> Also, as a comment about the docs (Hi Mike), the example PostAuthHook 
> in the manual (which the above is a shameless copy/adaptation of) 
> doesn't mention that the REJECT code might be REJECT_IMMEDIATE, not 
> just plain old REJECT. That had me fooled for a while! :)
> 
> Perhaps the docs could make a reference in that section to a complete 
> list of possible values of x for $main::x ...
> 
> Cheers,
>Simon
> 
> ---
> Simon Hackett, Technical Director, Internode Systems Pty Ltd
> 31 York St [PO Box 284, Rundle Mall], Adelaide, SA 5000 Australia
> Email: [EMAIL PROTECTED]  Web: http://www.on.net
> Phone: +61-8-8223-2999  Fax: +61-8-8223-1777
> 
> 
> ===
> 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.
> 

===
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) Access Denied ... 691 error....(Urgent)...

[Kitabjian, Dave]

Compare the secret you're using with radpwtst against the one you're using
in your config file...

Dave

> -Original Message-
> From: Mohammed AbdusSami [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, April 18, 2001 4:58 AM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: (RADIATOR) Access Denied ... 691 error(Urgent)...
> 
> 
> Hi...
> 
> My config is as follows...I am
> 
> can anybody tell why I am getting 691 error ( check password) 
> when I am able
> to authenticate with same password using radpwtst.
> 
> Your immediate help will be highly appreciated.
> 
> Best Regards,
> 
> Mohammed AbdusSami
> 
> # configuration
> 
> 
>   Secret  abcdefgh09876
>   DupInterval 0
> 
> 
> 
> 
>   Secret  radiator567
>   DupInterval 0
> 
> 
> 
> 
>   Identifier Check_Logins
>   DBSourcedbi:ODBC:radius
>   DBUsername  radiator
>   DBAuth  rad123456
>   AuthSelect  select password from logins \
>   Where username='%n' and status=0
> 
>   AccountingTable UsageOnlinehours
>   AcctColumnDef   USERNAME,User-Name
>   AcctColumnDef   TIME_STAMP,Timestamp,integer-date
>   AcctColumnDef   ACCTSTATUSTYPE,Acct-Status-Type
>   AcctColumnDef   ACCTDELAYTIME,Acct-Delay-Time,integer
>   AcctColumnDef   ACCTINPUTOCTETS,Acct-Input-Octets
>   AcctColumnDef   ACCTOUTPUTOCTETS,Acct-Output-Octets
>   AcctColumnDef   ACCTSESSIONID,Acct-Session-Id
>   AcctColumnDef   ACCTSESSIONTIME,Acct-Session-Time,integer
>   AcctColumnDef   ACCTTERMINATECAUSE,Acct-Terminate-Cause
>   AcctColumnDef   NASIDENTIFIER,NAS-Identifier
>   AcctColumnDef   NASPORT,NAS-Port,integer
>   AcctColumnDef   FRAMEDIPADDRESS,Framed-IP-Address
> 
>   AddToReply PoolHint = login, \
>   Service-Type = Framed-User, \
>   Framed-Protocol = PPP, \
>   Session-Timeout = 18000, \
>   Idle-Timeout = 18000, \
>   Framed-Compression = Van-Jacobson-TCP-IP
> 
> 
> 
> # configure AuthBy SQL to check emails (Identifier Check_Emails)
> 
>   Identifier Check_Emails
>   DBSourcedbi:ODBC:radius
>   DBUsername  radiator
>   DBAuth  rad123456
>   AuthSelect  select password from Emails \
>   Where popname='%n' and status=0
> 
>   AccountingTable EmailOnlinehours
>   AcctColumnDef   USERNAME,User-Name
>   AcctColumnDef   TIME_STAMP,Timestamp,integer-date
>   AcctColumnDef   ACCTSTATUSTYPE,Acct-Status-Type
>   AcctColumnDef   ACCTDELAYTIME,Acct-Delay-Time,integer
>   AcctColumnDef   ACCTINPUTOCTETS,Acct-Input-Octets
>   AcctColumnDef   ACCTOUTPUTOCTETS,Acct-Output-Octets
>   AcctColumnDef   ACCTSESSIONID,Acct-Session-Id
>   AcctColumnDef   ACCTSESSIONTIME,Acct-Session-Time,integer
>   AcctColumnDef   ACCTTERMINATECAUSE,Acct-Terminate-Cause
>   AcctColumnDef   NASIDENTIFIER,NAS-Identifier
>   AcctColumnDef   NASPORT,NAS-Port,integer
>   AcctColumnDef   FRAMEDIPADDRESS,Framed-IP-Address
> 
>   AcctFailedLogFileName %D/missedaccounting
> 
>   AddToReply PoolHint = email, \
>   Service-Type = Framed-User, \
>   Framed-Protocol = PPP, \
>   Session-Timeout = 18000, \
>   Idle-Timeout = 18000, \
>   Framed-Compression = Van-Jacobson-TCP-IP
> 
> 
> 
> # configure Realms (usernames will be of the form user@r1, or user@r2)
> 
> 
>   AuthBy Check_Logins
> 
> 
> 
>   AuthBy Check_Emails
> 
> 
> 
> ===
> 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.
> 

===
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) processing Acct-Session-Id field before it gets into the database

[Kitabjian, Dave]

Note this from the docs
(http://www.open.com.au/radiator/ref.html#pgfId=319543):

Hooks are executed at fixed times during request processing:

Server started 
StartupHook called 
Request received from NAS 
Global RewriteUsernames applied 
PreClientHook called 
Client clause selected 
Client RewriteUsernames applied 
Duplicate detection done 
PreHandlerHook called 
Handler selected 
PreProcessingHook called 
Handler's RewriteUsername and RewriteFunction applied 
Session database updated (accounting requests only) 
Accounting log files (AcctLogFileName and WtmpFileName) written 
PreAuthHook called 
AuthBy clauses invoked 
PostAuthHook called 
Reply sent to NAS (unless request was proxied) 
(if the request was proxied to another Radius server...) Reply received from
proxy server 
ReplyHook called 
Reply sent to NAS 
If no reply was received from a proxy server by AuthBy RADIUS, even after
multiple retransmissions and timeouts, NoReplyHook is called. 

Perhaps you're not looking in the right place at the right time?

Dave

> -Original Message-
> From: Feite Brekeveld [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, April 17, 2001 12:32 PM
> To: [EMAIL PROTECTED]
> Subject: (RADIATOR) processing Acct-Session-Id field before 
> it gets into
> the database
> 
> 
> Hi,
> 
> I would like to do some modification to the Acct-Session-Id 
> field before
> it gets logged into the database (Postgresql).
> 
> I did some experimenting with  the PreProcessingHandler but 
> it seems not
> to be run when a request comes in.
> 
> Please some tips on this one .
> 
> Thanks,
> 
> 
> Feite Brekeveld
> 
> 
> ===
> 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.
> 

===
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.

(RADIATOR) Enforcing Time Abuse

[Kitabjian, Dave]

We seem to have a constant chunk of ports hogged up by users who aren't
using the Internet "interactively". This kills our dialup resources (and
violates our Terms and Conditions).

We already have an Idle-Timeout set, but that doesn't catch people who have
AIM running, or who set Eudora to automatically check their mail every 10
minutes, since they pass data. And we don't want to use Session-Timeout
since that will kick them off even if they're "active" at the time of the
Timeout.

So...

What we'd really like is a "parametrized Idle-Timeout": an Idle-Timeout that
will kick you off if your recent usage falls BELOW AN ADJUSTABLE THRESHOLD
of bytes/minute. Is there such a thing?

Another option might be a "conditional Session-Timeout": after
Session-Timeout is exceeded, prompt the user if he needs to remain
connected, and if there is no reply after X minutes, disconnect them. Is
this possible?

Or, what other solutions are out there for attacking this problem?

Thanks in advance!

Dave

===
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.

(RADIATOR) evaluating & comparing Steel-Belted Radius

[Kitabjian, Dave]

Well,

This year (as last year) I am being presented by my management with
Steel-Belted Radius glossies and a trial CD, and all the features it
supports. I have a feeling they have a pretty strong presence at ISP-CON (is
Radiator there?).

Is there a comparison chart that has been done to show how the features
differ between the two products? (I'm going to ask the same question to Funk
Software).

I'm not sure what they mean by "wireless", "VPN/tunnel", and "broadband",
but as long as they talk Radius I'm not sure why Radiator couldn't support
them similarly. We're talking about using the "time of day" restrictions,
but that should be controllable via standard Reply Items, right? Also, we
want to turn on port-limit enforcement, and I know Radiator supports that,
and I don't see what advantage their Concurrency Server option offers.

Any comments and feedback is welcome!

Dave

===
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) RewriteUsername in ?

[Kitabjian, Dave]

Ahh, I see. Sorry I didn't think of that. 

Would I be correct in assessing this AuthBy GROUP as behaving sort of like a
quasi-Handler? It seems that it offers some Handler-like control...

Thanks!

Dave
:)

> -Original Message-
> From: Hugh Irvine [mailto:[EMAIL PROTECTED]]
> Sent: Friday, January 01, 1904 5:31 AM
> To: Kitabjian, Dave; '[EMAIL PROTECTED]'
> Cc: Wild, Andrew
> Subject: Re: (RADIATOR) RewriteUsername in  ?
> 
> 
> 
> Hello Dave -
> 
> The way to do this is with AuthBy GROUP(s):
> 
...
> 
> Hugh
> 
> 
> At 16:56 -0500 01/3/27, Kitabjian, Dave wrote:
> >Subject says it all.
> >
> >The docs say you can specify RewriteUsername Globally, in 
> Client clauses,
> >and in Realms. (It might be worth mentioning that it appears 
> to work in
> >non-realm Handlers, too.)
> >
> >But anyway...
> >
> >I'm wondering if it can work in  clauses?
> >
> >The reason we'd like that is as follows. We do a 
> RewriteUsername to strip
> >out garbled characters before passing requests onto LDAP, 
> since it will hang
> >LDAP (and sometimes Radiator :-( ). We don't know which 
> Clients will end up
> >using the AuthBy LDAP, and the requests may arrive via other 
> Handlers, too.
> >So the logical place to put it is in the AuthBy. Otherwise, 
> we'll have to
> >make sure to specify it in each Handler, which is less than elegant.
> >
> >Does this make sense?
> >
> >Thanks!
> >
> >Dave
> >NetCarrier

===
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.

(RADIATOR) RewriteUsername in ?

[Kitabjian, Dave]

Subject says it all. 

The docs say you can specify RewriteUsername Globally, in Client clauses,
and in Realms. (It might be worth mentioning that it appears to work in
non-realm Handlers, too.)

But anyway...

I'm wondering if it can work in  clauses?

The reason we'd like that is as follows. We do a RewriteUsername to strip
out garbled characters before passing requests onto LDAP, since it will hang
LDAP (and sometimes Radiator :-( ). We don't know which Clients will end up
using the AuthBy LDAP, and the requests may arrive via other Handlers, too.
So the logical place to put it is in the AuthBy. Otherwise, we'll have to
make sure to specify it in each Handler, which is less than elegant.

Does this make sense?

Thanks!

Dave
NetCarrier


===
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.

(RADIATOR) How is Postgresql or Postgres pronounced?

[Kitabjian, Dave]

This has been bugging me for some time. And before I let management get away
with their guess at the pronunciation, I'd like to know if any of you know
how this is *supposed* to be pronounced?

Sleepless,

Dave
:)

> -Original Message-
> From: Hugh Irvine [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, March 14, 2001 6:23 PM
> To: Dave Price; [EMAIL PROTECTED]
> Subject: Re: (RADIATOR) Problems with SQL (postgresql) loggng
> 
> 
> 
> Hello Dave -
> 
> On Thursday 15 March 2001 01:04, Dave Price wrote:
> > This used to work ... we upgraded both perl and radiator, 
> now the logging
> > to postgres failed ... here are the log entries i see:

===
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) SQL Timeout when purging ACCOUNTING table

[Kitabjian, Dave]

My experience with such things is that it's a database contention problem:
the process of purging the table can easily (for Sql Server) escalate to a
table-lock, blocking any further Insert attempts.

I had to write a routine that would drop into a loop and delete one row at a
time, referring to that row exclusively by its Primary Key. That way, the
DBMS could find the row using the table index, and a table lock was hence
not necessary. This worked for me.

Another thing to consider is that the purge could simply be pegging the CPU
on the DB server (we've seen this, too). This is a lot easier to check: use
"top" on Unix or else Task Manager in NT.

Dave

> -Original Message-
> From: Janet N. del Mundo [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, March 13, 2001 5:16 PM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Re: (RADIATOR) SQL Timeout when purging ACCOUNTING table
> 
> 
> Hi Hugh,
> 
> The missedaccounting file contained just the accounting stop records. 
> Yes, I waited for about 30 mins. and authentication requests 
> started to
> be rejected.  That's when I had to restart Radiator.  What can I do to
> not interrupt the users authentication?  Would it make any 
> difference if
> I use just a regular flat file, and not the 'AcctFailedLog...' feature
> to capture start and stop records?
> 
> Thanks,
> Janet
> 
> Hugh Irvine wrote:
> > 
> > Hello Janet -
> > 
> > What data is contained in the AcctFailedLogFileName file? 
> Did it actually
> > catch the accounting data? Notice that this will only catch 
> accounting stops
> > as sessions end, and as the debug shows, Radiator will not retry the
> > connection for 10 minutes (600 seconds) - did you wait that 
> long to see if it
> > would re-establish?
> > 
> > regards
> > 
> > Hugh
> > 
> > On Tuesday 13 March 2001 15:58, Janet N. del Mundo wrote:
> > > Hi everyone,
> > >
> > > Radiator still times out connecting to the SQL server 
> when we do a month
> > > end purge of old accounting data and our users are unable to
> > > authenticate.  I thought by using the 
> 'AcctFailedLogFileName' feature,
> > > the accounting data would default to this flat file and 
> not interrupt
> > > user authentication.  However, we just did a purge of old 
> data and I had
> > > to restart Radiator when the purge process was done.  
> What can I do to
> > > avoid this problem?
> > >
> > > log file:
> > > -
> > > Mon Mar 12 07:40:12 2001: ERR: Could not connect to SQL 
> database with
> > > DBI->connect dbi:ODBC:, x, x:  
> [OpenLink][ODBC]exceeded
> > > maximum number of allowed connections (SQL-08004)
> > > [OpenLink][ODBC]Connection rejected by data source (SQL-08004)
> > > [OpenLink][ODBC]exceeded maximum number of allowed connections
> > > (SQL-08004)
> > > [OpenLink][ODBC]Connection rejected by data source 
> (SQL-08004)(DBD:
> > > db_login/SQLConnect err=-1)
> > > Mon Mar 12 07:40:12 2001: ERR: Could not connect to any 
> SQL database.
> > > Request is ignored. Backing off for 600 sec
> > > onds
> > >
> > > config file:
> > > 
> > > 
> > > Identifier SQL
> > > DBSource dbi:ODBC:x
> > > DBUsername x
> > > DBAuth x
> > >
> > > AuthSelect select Password, Expiration, SimUse, \
> > > IdleTime, SessionTime, StaticIP \
> > > from USERS where IDENTIFIER = '%n' AND 
> STATUS != 'C'
> > >
> > > AuthColumnDef 1, Expiration, check
> > > AuthColumnDef 2, Simultaneous-Use, check
> > > AuthColumnDef 3, Idle-Timeout, reply
> > > AuthColumnDef 4, Session-Timeout, reply
> > > AuthColumnDef 5, Framed-IP-Address, reply
> > >
> > > AccountingTable ACCOUNTING
> > >
> > > AcctColumnDef   IDENTIFIER,User-Name
> > > AcctColumnDef   
> TIME_STAMP,Timestamp,formatted-date,'%m-%d-%Y
> > > %H:%M:%S'
> > > AcctColumnDef   DURATION,Acct-Session-Time,integer
> > > AcctColumnDef   ACCTSTATUSTYPE,Acct-Status-Type
> > > AcctColumnDef   ACCTDELAYTIME,Acct-Delay-Time,integer
> > > #AcctColumnDef   ACCTINPUTOCTETS,Acct-Input-Octets,integer
> > > #AcctColumnDef   
> ACCTOUTPUTOCTETS,Acct-Output-Octets,integer
> > > AcctColumnDef   ACCTSESSIONID,Acct-Session-Id
> > > AcctColumnDef   ACCTTERMINATECAUSE,Acct-Terminate-Cause
> > > #AcctColumnDef   NASIDENTIFIER,NAS-Identifier
> > > AcctColumnDef   NASIDENTIFIER,NAS-IP-Address
> > > AcctColumnDef   NASPORT,NAS-Port,integer
> > > AcctColumnDef   FRAMEDIPADDRESS,Framed-IP-Address
> > > AcctColumnDef   CONNECTSPEED,Connect-Info
> > > AcctColumnDef   CONNECTSPEED,USR-Connect-Speed
> > > AcctColumnDef   CALLERID,Calling-Station-Id
> > > AcctColumnDef   POPID,Called-Station-Id
> > >
> > > # You can arrange to log accounting to a file if the
> > > # SQL insert fails with AcctFailedLogFileName
> > > # That way you could recover 

RE: (RADIATOR) ServerHasBrokenPortNumbers

[Kitabjian, Dave]

> On Saturday 10 March 2001 01:33, Kitabjian, Dave wrote:
> > I was reading the writeup on this interesting feature:
> >
> > "ServerHasBrokenPortNumbers
> >
> > "Some Radius servers (GRIC on NT in particular) exhibit broken
> > behaviour in that the reply does not come from the same UDP 
> port that the
> > request was sent to! "
> >
> > We have a similar sounding problem, but from some of our 
> Radius CLIENTS:
> >
> > Fri Mar  9 09:26:08 2001: DEBUG: Packet dump:
> > *** Received from 207.201.82.17 port 1646 
> > Code:   Accounting-Request
> >
> > All (but one) of our NASes are reaching us on ports 
> 1812/1813, and those
> > ports were always reflected in the "*** Received from..." 
> lines in our
> > Debug 4 logfile. That was all with USR gear. Now that we've 
> added Cisco
> > gear, they are often showing 1645/1646, like in the above 
> logfile clipping
> > EVEN THOUGH they are actually communicating to Radiator on 
> ports 1812/1813!
> >
> > Any idea what the reason for that is, and if it has 
> anything to do with the
> > ServerHasBrokenPortNumbers issue?
> >
> 
> You can do some experiments with radpwtst to see what port 
> numbers it uses 
> for its own end of its communications with Radiator (on my 
> box its 1028).

"True, true" (if I can quote a popular Budweiser commercial.

> In theory a client can 
> use any UDP 
> port number it likes for its own end of the communication, 
> and in fact it is 
> rarely the same port number as the server end. ...

Oh...but isn't the logfile showing the SERVER's port rather than the
CLIENT's port? I guess I always assumed it was the server's port.
 
> Why do you say that the above is causing difficulty?

Just that, in the past, (I thought) I had used the:

*** Received from 207.201.82.17 port 1646 

entries in the logfile to confirm which NASes were communicating with me on
the new ports, so I could tell when it was safe to turn off the copy of
radiusd listening on the old ports, 1645/1646. But perhaps I was confused...

Dave
:)

===
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.

(RADIATOR) ServerHasBrokenPortNumbers

[Kitabjian, Dave]

I was reading the writeup on this interesting feature:

"ServerHasBrokenPortNumbers

"Some Radius servers (GRIC on NT in particular) exhibit broken
behaviour in that the reply does not come from the same UDP port that the
request was sent to! "

We have a similar sounding problem, but from some of our Radius CLIENTS:

Fri Mar  9 09:26:08 2001: DEBUG: Packet dump:
*** Received from 207.201.82.17 port 1646 
Code:   Accounting-Request

All (but one) of our NASes are reaching us on ports 1812/1813, and those
ports were always reflected in the "*** Received from..." lines in our Debug
4 logfile. That was all with USR gear. Now that we've added Cisco gear, they
are often showing 1645/1646, like in the above logfile clipping EVEN THOUGH
they are actually communicating to Radiator on ports 1812/1813!

Any idea what the reason for that is, and if it has anything to do with the
ServerHasBrokenPortNumbers issue?

Dave 

===
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: IMPORTANT - Re: (RADIATOR) purpose of ContinueUntilIgnore?

[Kitabjian, Dave]

Excellent and informative reply.

So the magic piece of information is "the result returned is the result of
the last AuthBy in the sequence". The manual glances at this idea:

http://www.open.com.au/radiator/ref.html#12824

but it might not hurt to be more explicit in the manual...

This is a great feature, and part of what is making Radiator a joy to work
with, and will probably make our upcoming integration with another ISP a
breeze. Thanks for a great product!

Dave

> -Original Message-
> From: Hugh Irvine [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, March 08, 2001 6:42 PM
> To: Kitabjian, Dave; [EMAIL PROTECTED]
> Subject: IMPORTANT - Re: (RADIATOR) purpose of ContinueUntilIgnore?
> 
> 
> 
> Hello Dave -
> 
> On Friday 09 March 2001 09:05, Kitabjian, Dave wrote:
> > I'm trying to understand the logic of the various 
> AuthByPolicies, and this
> > one leaves me confused. Aside from how it would be useful, 
> I'd like to know
> > what it returns?
> >
> > Since it doesn't return until it gets an ignore, it 
> presumably doesn't
> > return any of the preceding results. And then it "succeeds" 
> by getting
> > Ignored, in which case there is again no result. So what 
> will it return? An
> > Ignore?
> >
> > Similarly, correct me if I'm wrong, but wouldn't ContinueUntilReject
> > guarantee that nobody will ever be able to log in, since no 
> results will be
> > sent to the client until the result is a Reject?
> >
> 
> You will need to understand something about the Radius 
> protocol design first, 
> and then something about the Radiator design.
> 
> First Radius. Keep in mind that "Ignore" (no response) is perfectly 
> reasonable behaviour in the context of the Radius protocol, 
> because that is 
> what causes a NAS to failover to a secondary Radius host. 
> Note that this is 
> the only behaviour that makes sense here as either an Accept 
> or a Reject will 
> cause the NAS to do something else.
> 
> Next Radiator. Also keep in mind that the AuthByPolicy 
> parameters are the 
> control specifications for the sequence of processing, not 
> what will be 
> returned to the NAS. With ContinueUntilIgnore, if there is 
> not an Ignore 
> during the sequence of AuthBy's, the result returned is the 
> result of the 
> last AuthBy in the sequence. Idem for ContinueUntilReject - 
> as long as you 
> don't get a Reject, you continue processing and the result of 
> the last AuthBy 
> is what is returned.
> 
> Note also that some of the AuthByPolicy's are inverse 
> statements of the same 
> condition and are only included for completeness and for ease of 
> specification for those who think differently.
> 
> regards
> 
> Hugh

> 

===
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.

(RADIATOR) purpose of ContinueUntilIgnore?

[Kitabjian, Dave]

I'm trying to understand the logic of the various AuthByPolicies, and this
one leaves me confused. Aside from how it would be useful, I'd like to know
what it returns?

Since it doesn't return until it gets an ignore, it presumably doesn't
return any of the preceding results. And then it "succeeds" by getting
Ignored, in which case there is again no result. So what will it return? An
Ignore?

Similarly, correct me if I'm wrong, but wouldn't ContinueUntilReject
guarantee that nobody will ever be able to log in, since no results will be
sent to the client until the result is a Reject?

Thanks! 

Dave

===
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) 99% CPU usage on Linux

[Kitabjian, Dave]

What  clauses are you using in your config file?

We found a bug in AuthBy LDAP2 which messes up Radiator when certain garbled
usernames are passed in, and the cpu gets pegged.

I've already alerted Radiator regarding this bug, and the solution for the
meanwhile is to use a RewriteUserName clause to throw out anything but A-Z,
a-z, 0-9, etc.

Dave

> -Original Message-
> From: Viraj Alankar [mailto:[EMAIL PROTECTED]]
> Sent: Friday, February 23, 2001 1:50 PM
> To: [EMAIL PROTECTED]
> Subject: (RADIATOR) 99% CPU usage on Linux
> 
> 
> 
> Hello,
> 
>   We recently switched from Solaris to Linux running Radiator. At
> some point, the radiusd process on the Linux box goes to 99% 
> CPU usage and
> becomes sluggish when responding to auth/acct. It does respond, but
> definitely alot slower than it should.
> 
> 'top' shows me:
> 
>   PID USER PRI  NI  SIZE  RSS SHARE STAT  LIB %CPU %MEM   
> TIME COMMAND
>  1832 admin 20   0 16052  15M  1228 R   0 98.6  3.1 
> 405:23 radiusd
> 
> load avg is always 1 understandably:
> 
>   1:45pm  up 1 day,  4:17,  1 user,  load average: 1.00, 1.00, 1.00
> 
>   I'm wondering what's going on here. Radiator runs fine 
> for awhile,
> hovering around 30-40% CPU usage, but then at some point it 
> goes to 99%.
> 
>   On our Solaris machine, it was always 40-60% from a 'top'.
> 
> We are using v2.17.1. The Linux machine is a P3-800 512M RAM, and the
> Solaris machine was an E250 450mhz (single) CPU 1G RAM.
> 
> Any help appreciated.
> 
> Viraj.
> 
> 
> ===
> 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.
> 

===
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) Cisco AS5300 VoIP / Radiator

[Kitabjian, Dave]

> ...One interesting thing to 
> note is that the AS5300 seems to be sending a null User-Name 
> ("") when they use account/PIN.

That seems odd to me. After the initial "pre-authentication", as the
documents suggest, ours prompts for an Account Number and PIN, and the
Gateway plugs them into the RADIUS Username and Password attributes,
respectively.

However, you can probably get this behavior to be anything you want based on
what IVR script you select in the Gateway...

Dave

===
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) (Fwd) Re: Radiator / Cisco prepaid calling cards

[Kitabjian, Dave]

Craig,

We're currently in the development stage of doing Cisco/Voip/Prepaid, and
it's mostly working fine.

Perhaps you could describe what particular problem you are having or what
specific question you have, and I could be of more assistance...

Dave

> -Original Message-
> From: Mike McCauley [mailto:[EMAIL PROTECTED]]
> Sent: Friday, February 09, 2001 10:41 AM
> To: [EMAIL PROTECTED]
> Subject: (RADIATOR) (Fwd) Re: Radiator / Cisco prepaid calling cards
> 
> 
> 
> Can anyone help Craig?
> 
> --- Forwarded mail from [EMAIL PROTECTED]
> 
> From: "Craig Thompson" <[EMAIL PROTECTED]>
> To: "Mike McCauley" <[EMAIL PROTECTED]>
> Date: Thu, 8 Feb 2001 17:29:55 -0500
> Subject: Re: Radiator / Cisco prepaid calling cards
> Reply-to: [EMAIL PROTECTED]
> 
> We saw the dictionary entries, but it could be the Cisco is 
> not configured
> correctly.  Know anyone else doing this that I could contact?
> 
> > Hi Craig,
> >
> > All the h323 attributes described in that document are 
> supported by Radiator.
> > You can also find an example of using them in the Radiator FAQ
> > http://www.open.com.au/radiator/faq.html
> >
> > Cheers.
> >
> >
> >
> > On Feb 8, 11:53am, Craig Thompson wrote:
> > > Subject: Radiator / Cisco prepaid calling cards
> > > Can you look at this URL:
> > >
> > > http://www.cisco.com/warp/public/cc/so/neso/vvda/pctl/distrib/pp
> > > cex_qp.htm
> > >
> > > It describes a service that we are trying to offer.  As well,
> > > the document (near the bottom) lists their RADIUS interface
> > > specs available at this address:
> > >
> > > http://www.cisco.com/warp/public/cc/cisco/mkt/servprod/packet/di
> > > strib/radus_ov.htm.
> > >
> > > Is this something that Radiator already does?  If it doesn't,
> > > what would it take to implement it?
> > >
> > > Thanks so much for your help.
> > >
> > >
> > >
> > > Craig Thompson, Manager
> > > WingNET Internet Services,
> > > P.O. Box 2605 // Cleveland, TN 37320-2605
> > > 423-559-LINK (v)  423-559-5145 (f)
> > > http://www.wingnet.net
> > >
> > >-- End of excerpt from Craig Thompson
> >
> >
> >
> > --
> > Mike McCauley   [EMAIL PROTECTED]
> > Open System Consultants Pty. LtdUnix, Perl, 
> Motif, C++, WWW
> > 24 Bateman St Hampton, VIC 3188 Australia   http://www.open.com.au
> > Phone +61 3 9598-0985   Fax   +61 3 9598-0955
> >
> > Radiator: the most portable, flexible and configurable RADIUS server
> > anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
> > Platypus, Freeside, TACACS+, PAM, external, Active Directory etc etc
> > on Unix, Win95/8, 2000, NT, MacOS 9, MacOS X
> >
> 
> 
> 
> Craig Thompson, Manager
> WingNET Internet Services,
> P.O. Box 2605 // Cleveland, TN 37320-2605
> 423-559-LINK (v)  423-559-5145 (f)
> http://www.wingnet.net
> 
> 
> 
> ---End of forwarded mail from [EMAIL PROTECTED]
> 
> -- 
> Mike McCauley   [EMAIL PROTECTED]
> Open System Consultants Pty. LtdUnix, Perl, 
> Motif, C++, WWW
> 24 Bateman St Hampton, VIC 3188 Australia   http://www.open.com.au
> Phone +61 3 9598-0985   Fax   +61 3 9598-0955
> 
> Radiator: the most portable, flexible and configurable RADIUS server 
> anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, 
> Platypus, Freeside, TACACS+, PAM, external, Active Directory etc etc 
> on Unix, Win95/8, 2000, NT, MacOS 9, MacOS X
> ===
> 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.
> 

===
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) dictionary issue - log complains of missing values

[Kitabjian, Dave]

I know what your problem is.

We have the same problem. Your accounting is no doubt coming back as:

cisco-h323-disconnect-cause = "h323-disconnect-cause=10"

My guess is that Cisco is hoping attributes such as "h323-disconnect-cause"
become RADIUS standards. Unfortunately, they haven't yet, so they have to
prefix all their stuff with "cisco-" since it's really proprietary to them
still. But in the VALUE itself, they have embedded the "proposed" name for
the attribute, h323-disconnect-cause, along with the value.

What I just finished doing was modifying our parsing algorithm for our
accounting data. Now, when it sees a prefix such as "cisco-", it searches
the value to find the "true" attribute name (along with the value). That
solves the attribute problem. But you're still stuck with the numeric "10"
as the value. I don't think there's any easy way around that unless you can
get the Gateway to stop embedding the attributes like this in the first
place.

If you DO find the way to get the Gateway to fix this, let me know!!

Dave
:)

> -Original Message-
> From: Ken Sain [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, January 23, 2001 9:45 AM
> To: [EMAIL PROTECTED]
> Subject: (RADIATOR) dictionary issue - log complains of missing values
> 
> 
> radiator 2.17.1
> mysql 3.22.32
> cisco 5300
> 
> for almost every single call, i get the following error in my 
> log file:
> 
> 22/01/2001 23:24
>   There is no value named h323-disconnect-cause=10 for
> attribute cisco-h323-disconnect-cause. Using 0.
> 
> however, in my dictionary file:
> 
> VENDORATTR  9 cisco-h323-disconnect-cause 30 string
> and
> # Voice return codes. REVISIT: whats the VENDORATTR?
> VALUE   cisco-h323-disconnect-cause   Success-Proceed 
> 0
> VALUE   cisco-h323-disconnect-cause   
> Failed-Invalid-Account  1
> VALUE   cisco-h323-disconnect-cause   
> Failed-Invalid-Password 2
> VALUE   cisco-h323-disconnect-cause   
> Failed-Account-In-Use   3
> VALUE   cisco-h323-disconnect-cause   Failed-Zero-Balance 
> 4
> VALUE   cisco-h323-disconnect-cause   Failed-Card-Expired 
> 5
> VALUE   cisco-h323-disconnect-cause   Failed-Credit-Limit 
> 6
> VALUE   cisco-h323-disconnect-cause   Failed-User-Denied  
> 7
> VALUE   cisco-h323-disconnect-cause   
> Failed-Service-Not-Available8
> VALUE   cisco-h323-disconnect-cause   
> Failed-Called-Number-Blocked9
> VALUE   cisco-h323-disconnect-cause   
> Failed-Num-Of-Retries-Exceeded  10
> VALUE   cisco-h323-disconnect-cause   
> Failed-Invalid-Argument 11
> VALUE   cisco-h323-disconnect-cause   Back-To-PSTN
> 50
> VALUE   cisco-h323-disconnect-cause   
> Redirect-To-Called-Party51
> VALUE   cisco-h323-disconnect-cause   
> Redirect-To-Customer-Service52
> VALUE   cisco-h323-disconnect-cause   
> Connect-Leg-To-Redirect-Addr53
> 
> only thing i can think of is that like with some other of 
> these cisco VSA's,
> you have to tweak the values to be 'cisco-h323-disconnect-cause=10'
> 
> any one seen this, and know if i'm correct?
> 
> thanks!
> 
> #---#
> # Ken Sain [EMAIL PROTECTED]   #
> # Systems Administrator  850.309.7999 - 
> office#
> # Genesis Communications Network   888.598.8942 - pager   #
> #---#
> 
> ===
> 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.
> 

===
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) Dictionary for Cisco Voip VSAs ??

[Kitabjian, Dave]

I'm very sorry for the post -- I found the necessary dictionary attributes:

http://www.open.com.au/radiator/downloads/patches-2.17.1/dictionary

Dave

> -Original Message-
> From: Kitabjian, Dave [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, January 10, 2001 10:46 AM
> To: '[EMAIL PROTECTED]'
> Subject: (RADIATOR) Dictionary for Cisco Voip VSAs ??
> 
> 
> I asked once before if anyone knew where to find the 
> dictionary for Cisco's
> Voip VSA's, and no one replied. 
> 
> So, I'm asking once more, since if no one replies by tomorrow, I will
> probably have to type it all in myself :(
> 
> Please, let me know!
> 
> Dave
> 
> p.s. I've searched Cisco's web site quite extensively already.
> 
> ===
> 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.
> 

===
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.

(RADIATOR) Dictionary for Cisco Voip VSAs ??

[Kitabjian, Dave]

I asked once before if anyone knew where to find the dictionary for Cisco's
Voip VSA's, and no one replied. 

So, I'm asking once more, since if no one replies by tomorrow, I will
probably have to type it all in myself :(

Please, let me know!

Dave

p.s. I've searched Cisco's web site quite extensively already.

===
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) Tunning the environment

[Kitabjian, Dave]

Also, see the "Performance and Tuning" section in the manual:

http://www.open.com.au/radiator/ref.html#pgfId=406539

There's some good stuff there.

Dave

> -Original Message-
> From: Hugh Irvine [mailto:[EMAIL PROTECTED]]
> Sent: Monday, December 18, 2000 5:19 PM
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: (RADIATOR) Tunning the environment
> 
> 
> 
> Hello Julio -
> 
> At 11:20 +0100 18/12/00, [EMAIL PROTECTED] wrote:
> >hi radiators,
> >
> >our scenario is a 3-layer architecture with the following:
> >
> >NAS Clients -> Proxy Radiator -> Radiator (with mysql in 
> local) -> LDAP
> >
> >We are making some tunning in the systems. In case of Radiator we set
> >"SocketQueueLength"
> >up to 15.
> >
> >So anyone has made tunning of Radiator, mysql, LDAP or tcp 
> in a similar
> >architecture?
> >
> >We're using Solaris, any recommendations in tcp tunning in a Radiator
> >environment?
> 
> The place to start for tuning purposes, is a trace 4 debug so you can 
> see where your timje is being spent. In the environment described 
> above, I would suspect the vast majority of the delays to occur in 
> the SQL and LDAP processing.
> 
> There have been various discussions about performance on the list, so 
> check the archive site:
> 
>   http://www.starport.net/~radiator
> 
> regards
> 
> Hugh

===
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.