(RADIATOR) signal to NAS
hello, just wondering if RADIATOR can send a signal to NAS to disconnect a particular usercan RADIATOR do that? if yes , how? = ) thanks lloyd inter.net philippines incorporated === 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 load problem
Thanx :) God knows how long that's been there, I've only just been assigned this box... Thought you said nothing had changed ;-) /Ingvar Cheers, David Napier === 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 and Merit-AAA 4.5
Hello Rafi - Vendor 2352 is Redback, so you should add the Redback vendor specifics to the standard dictionary file with your favourite text editor (from dictionary.redback). The problem with the accounting requests can probably be fixed with the following: # define Merit Client clause with IgnoreAcctSignature Client . Secret . IgnoreAcctSignature . /Client To say any more, I will have to see a copy of your configuration file (no secrets) together with a trace 4 debug from Radiator showing what is happening. regards Hugh On Thursday 18 October 2001 14:00, Muhammed, Rafi wrote: We are testing a ADSL set-up where in remote routers are connected to the corporate network through an ISP The corporate network connects to the ISP over 2M Frame relay link. The individual remote sites are connected to the ISP over ADSL. For Authentication, the ISP uses Merit-AAA 4.5 Radius Server and proxies it to our Radiator server in our corporate LAN. The problem is the accounting requests never complete and they generate lot of errors as shown below Thu Oct 18 15:54:51 2001: ERR: Attribute number 211 (vendor ) is not defined in your dictionary Thu Oct 18 15:54:51 2001: ERR: Attribute number 211 (vendor ) is not defined in your dictionary Thu Oct 18 15:54:51 2001: ERR: Attribute number 4 (vendor 2352) is not defined in your dictionary Thu Oct 18 15:54:51 2001: ERR: Attribute number 15 (vendor 2352) is not defined in your dictionary Thu Oct 18 15:54:51 2001: ERR: Attribute number 128 (vendor 2352) is not defined in your dictionary Thu Oct 18 15:54:51 2001: ERR: Attribute number 129 (vendor 2352) is not defined in your dictionary Thu Oct 18 15:54:51 2001: ERR: Attribute number 130 (vendor 2352) is not defined in your dictionary Thu Oct 18 15:54:51 2001: ERR: Attribute number 131 (vendor 2352) is not defined in your dictionary Thu Oct 18 15:54:51 2001: ERR: Attribute number 222 (vendor ) is not defined in your dictionary Thu Oct 18 15:54:51 2001: ERR: Attribute number 223 (vendor ) is not defined in your dictionary Due to this the authentication never completes and we see lot of authentication requests after one access request, and the process repeats continuously. Is there a dictionary file to address this problem? Thanks Muhammed Rafi === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message. -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X. - Nets: internetwork inventory and management - graphical, extensible, flexible with hardware, software, platform and database independence. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Radiator load problem
Hello David - On Thursday 18 October 2001 11:57, David Napier wrote: Thanx for the reply High, can't fault this service :) We try to please. Actually, we try to be *much* better than any other product and any other support you have ever seen. The first question of course is what has changed?. According to logs, nothing. We use /etc/password for userlists on this box and only the usual additions and deletions have occured. We do have a few users explicitly mentioned in /etc/raddb/user, and one new user added there, however the syntax is fine (ie, exactly like the 300 before it) as its all script generated. I've grilled other admins and no-one knows anything :/ H. The second question is how do you start radiusd?. We start via the command `/usr/bin/radiusd -config_file /etc/raddb/radiator.cfg`. I am uncertain whether this was bundled with radiator or someone else scripted it. This doesn't answer my question. What I want to know is how do multiple copies of Radiator get started?. If you should only have one copy running and all of a sudden there are many copies running, then something is clearly amiss. And the third question is can you please send me a copy of the configuration file (no secrets) together with a trace 4 debug showing what is going on?. Attached below, with all scarey info 'd. I haven't attached a trace 4 as I haven't got a sample with radius chomping cpu yet. Hopefully we won't have to wait long (or hopefully we will :) Thanks, but unfortunately most of the interesting bits are in the Include files, so I can't really see much. regards Hugh -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X. - Nets: internetwork inventory and management - graphical, extensible, flexible with hardware, software, platform and database independence. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) insert errors
--On Tuesday, October 16, 2001 09:57:17 AM +0200 Jesús M Díaz
[EMAIL PROTECTED] wrote:
Hello,
i had the same problem too, but whit the pair 'nas-identifier/nas-port'.
i could solve it changing the AddQuery sentence at 'session sql' clause
from 'insert into ...' to 'replace into ...'.
the problem, as i could see, is when due an error or any other reason,
Radiator keeps a session entry but that sessions is not real yet.
regards
I don't really know if your problem is related to mine, but in our
configuration (big ISP, about 80 requests/s) we had a lot of duplicates. To
avoid this we patched Radiator to handle real duplicates.
For that, we match packets not only on packet ID, but on NAS IP and UDP
port Number (because some hosts like Lucent TNT have multiple ID space on
different port numbers). The patch is working perfectly.
Maybe this patch could be integrated into official release ?
Here it is for Radiator 2.18.4:
--8X cut here 8X--
*** Radius/Client.pm.oldWed Oct 3 15:28:46 2001
--- Radius/Client.pmWed Oct 3 15:27:55 2001
***
*** 6,21
# Namethe host name the Client was created with
# HostPacked host address of the client
#
# In order to detect duplicate arrivals, we keep an array
! # of arrivals ($self-{RecentIdentifiers})indexed by the Radius packet
! # identifier (8 bits), concatenated with the packet type code.
# (The packet code is used because some NASs use different packet
# sequences for different request types)
# The value stored in each element of the array is the time
! # we last received
! # a packet with that identifier from this client.
! # If the time interval is
! # less than DupInterval, the packet is assumed to be
# duplicate, and is ignored
#
# Author: Mike McCauley ([EMAIL PROTECTED])
--- 6,23
# Namethe host name the Client was created with
# HostPacked host address of the client
#
+ # Patch by [EMAIL PROTECTED] (the old code did not use the IP
address):
# In order to detect duplicate arrivals, we keep an array
! # of arrivals ($self-{RecentIdentifiers})indexed by
! # the IP address of the host that sent the request,
! # the UDP port number (some hosts like Lucent TNT have multiple ID space
! # on different port numbers), the Radius packet identifier (8 bits),
! # concatenated with the packet type code.
# (The packet code is used because some NASs use different packet
# sequences for different request types)
# The value stored in each element of the array is the time
! # we last received a packet with that identifier from this client.
! # If the time interval is less than DupInterval, the packet is assumed to
be
# duplicate, and is ignored
#
# Author: Mike McCauley ([EMAIL PROTECTED])
***
*** 307,313
# accounting where the Acct-Delay-Time has changed, because
# the identifier will also have changed. Gag.
if (!$self-{NoIgnoreDuplicates}{$code}
!$self-{RecentIdentifiers}-{$nas_id . $code}[$p-identifier]
($p-{RecvTime} - $self-{DupInterval}))
{
if (!$is_reboot)
--- 309,315
# accounting where the Acct-Delay-Time has changed, because
# the identifier will also have changed. Gag.
if (!$self-{NoIgnoreDuplicates}{$code}
!$self-{RecentIdentifiers}-{$p-{RecvFrom} . $code}[$p-identifier]
($p-{RecvTime} - $self-{DupInterval}))
{
if (!$is_reboot)
***
*** 314,320
{
# Its a duplicate, log it and ignore it
my $id = $p-identifier;
! main::log($main::LOG_INFO, Duplicate request id $id received
from
$nas_id: ignored);
$self-{Statistics}{radiusServDupAccessRequests}++,
$main::statistics{radiusAuthServTotalDupAccessRequests}++
if $code eq 'Access-Request';
--- 316,326
{
# Its a duplicate, log it and ignore it
my $id = $p-identifier;
! my ($udpPort, $udpAddr) = Socket::unpack_sockaddr_in($p-{RecvFrom}
! );
! my ($udpAddrPrint) = Socket::inet_ntoa($udpAddr);
!
! main::log($main::LOG_INFO, Duplicate request id $id received
from
$udpAddrPrint($udpPort): ignored);
$self-{Statistics}{radiusServDupAccessRequests}++,
$main::statistics{radiusAuthServTotalDupAccessRequests}++
if $code eq 'Access-Request';
***
*** 327,333
else
{
# its not a dup, save the id for later dup checking
! $self-{RecentIdentifiers}-{$nas_id . $code}[$p-identifier]
= $p-{RecvTime};
# Call the PreHandlerHook, if there is one
--- 333,339
(RADIATOR) Block Time on RADMIN
Hello... I use RADMIN for manage user on MySQL.It's work ok.But I don't understand.Why RADMIN don't have some attribute check? .An attribute check is Block-Logon-From. I want to manage user with RADMIN. My issue : User can connect on Monday to Friday at 8:00 to 17:00 ( Block-Logon-From or Block-Logon-To or Time).If I config on a users file then it's ok.But on RADMIN haven't config that.Why? Please recommended me Best Regards, suwat.c __ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com === 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) Tunnel-Client-Auth-ID and Tunnel-Server-Auth-ID
Hello Hugh, == From: Hugh Irvine You are defining the attributes as vendor specifics, but Radiator is complaining about standard attributes. Here is how to define them: ATTRIBUTE Tunnel-Client-Auth-ID90 string ATTRIBUTE Tunnel-Server-Auth-ID91 string I have also copied this mail to Mike so he can add these to the standard dictionary. hth Yes, adding the above to lines to my dictionary made the error messages go away. Thanks. So I guess (vendor ) really means not vendor specific. Cheers, -Wim -/- SURFnet === 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) AddToReply also in accounting?
Hola Mariano, Hello Hugh, == From: Hugh Irvine Yes Mariano is correct in what is shown below. Note that there may or may not be reply attributes in accounting responses. Wim is right in saying that they are usually empty, but there are some applications (usually proxy setups) that require reply attributes in accounting responses as well as in access accepts. As Wim points out, AddToReply(IfNotExist) can be used in both cases. And as Mariano shows below, Handlers can be used to deal with authentication and accounting separately. The solution of Mariano could work. But my greatest problem is that is see something which is not correct according to the reference manual. According to the reference manual AddToReply adds attributes *to Access-Accepts*. But as I understand it now this should be adds attributes to (all) replies. Just a minor detail. Cheers, -Wim -/- SURFnet === 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) Need clarification on AuthSelect with AuthColumnDef
Can't seem to get radiator 2.18.4 to pass the correct reply items back to the nas. We used the default radmin.cfg, and implemented the changes at the top that are listed in the comments for if you want to add things like Framed-IP-Netmask, Idle-Timeout, etc. According to the Docs, you can specify your OWN Authselect, and then your AuthColumnDef should start at 0, with 0 being the first item passed back AFTER the required first four items. However, this doesn't seem to work (ie. the easy example of how to add things like Framed-IP-Netmask doesn't work). This isn't a database problem or anything, because it does get the Framed-IP-Address correctly for each user, but there is no Framed-IP-Netmask in the reply (shown with radpwtst -trace). Has anyone else run into this, and what is the fix? I have read the docs on AuthColumnDef and feel like there's some piece that I'm missing. The LAST attempt I made I tried specifying everything in the reply rather than just the additions (according to the docs, this isn't necessary, but I was out of other ideas...) AuthSelect select PASS_WORD,\ STATICADDRESS,TIMELEFT,MAXLOGINS,FRAMED_NETMASK,FRAMED_FILTER_ID,\ MAXIDLETIME \ from RADUSERS where \ USERNAME='%n' and BADLOGINS 5 and \ VALIDFROM %t and VALIDTO %t AuthColumnDef 0,User-Password,check AuthColumnDef 1,Framed-IP-Address,reply AuthColumnDef 2,Session-Timeout,reply AuthColumnDef 3,Session-Timeout,reply AuthColumnDef 4,Framed-IP-Netmask,reply AuthColumnDef 5,Filter-Id,reply AuthColumnDef 6,Idle-Timeout,reply This gets me no Framed-IP-Netmask in the radpwtst -trace But Here is the stock radmin.cfg from the radiator distribution, and I get the same results... # You can add extra items to your RADUSERS table and make # Radiator take note of them with, for example: # AuthSelect select PASS_WORD,STATICADDRESS,TIMELEFT,\ #MAXLOGINS,FRAMED_NETMASK,FRAMED_FILTER_ID,MAXIDLETIME \ #from RADUSERS where \ #USERNAME='%n' and BADLOGINS 5 and \ #VALIDFROM %t and VALIDTO %t # AuthColumnDef 0,Framed-IP-Netmask,reply # AuthColumnDef 1,Filter-Id,reply # AuthColumnDef 2,Idle-Timeout,reply # note that the numbering of AuthColumnDef starts with the # field following the first 4 minumum and required fields. This also gets me no Framed-IP-Netmask in the radpwtst -trace The net effect is we want a stock config, but with the addition of FRAMED_NETMASK, FRAMED_FILTER_ID, and MAXIDLETIME Any ideas??? Jay West === 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) Multiple Accounting Stop Records
Hello everyone, After some checking we've found out that the TotalControls cannot be configured to not retransmit accounting records. The problem is that we have these multiple stop records in the detail file which create a billing problem for us. Right now I run a perl script to cleanup the detail file, but I'm wondering whether the following will work. The idea is to only write to the accounting detail files the accounting start records and the accounting stop records that have an Acct-Delay-Time of 0. All other accounting requests would be ignored. Right now I use Handlers. In this setup I would replace each Handler in my current radius.cfg with 3 Handlers. This would be a one time pain, but I wouldn't have to run the perl script and everything would be right in the radius.cfg. Here goes: Handler Realm=domain.com Request-Type=Access-Request as before.with the AcctLogFileName line removed /Handler Handler Realm=domain.com Request-Type=Accounting-Request Acct-Status-Type=1 AcctLogFileName /var/log/radacct/detail /Handler Handler Realm=domain.com Request-Type=Accounting-Request Acct-Status-Type=2 Acct-Delay-Time=0 AcctLogFileName /var/log/radacct/detail /Handler Does it make sense? Do I need an AuthBy clause if I'm only handling Accounting-Request? Thanks in advance, William -Original Message- From: Hugh Irvine [mailto:[EMAIL PROTECTED]] Sent: Monday, August 27, 2001 7:43 PM To: William Hernandez; Radiator Subject: Re: (RADIATOR) Multiple Accounting Stop Records Hello William - What you are seeing is NAS retransmissions because the NAS has not received an Accounting-Response in reply to an Accounting-Request (or possibly a NAS bug). The radius retransmission timeout on the NAS must be set to 60 seconds if that is what you are seeing in the log file. Note that it is pretty simple to recognise the retransmissions simply by the fact that the Acct-Delay-Time is not 0. In other words, the first transmission of an accounting packet will have an Acct-Delay-Time of 0, the second will have an Acct-Delay-Time of whatever the radius retry timeout is set on the NAS, the third will have an Acct-Delay-Time of twice the radius retry timeout, etc. etc. The way to find out what is happening is to check a trace 4 debug from Radiator to verify that the first accounting packet in the series is indeed being replied to, and then use your favourite packet sniffer along the transmission path back to the NAS to verify whether the reply is getting back to the NAS. In our experience the vast majority of problems like this are the direct result of saturated links somewhere in the transmission path that cause packets to be dropped. hth Hugh On Tuesday 28 August 2001 04:04, William Hernandez wrote: We're having a problem with multiple accounting stop records. The stop records have exactly a 1 minute difference between them, ..i.e, a stop record at 09:00:00 is followed by another stop record at 09:00:01. We starting seeing these multiple accounting stop records about a month ago. This coincides with some changes we made to our systems, namely, upgrading to RedHat 7.1, upgrading to Radiator 2.18.1, and switching to TotalControl (HiperArc) NASes. I need help determining why we're getting there multiple stop records. Everything was working fine with Radiator 2.16 and with the Ascend Maxes we were previously using. I found some messages in the archives about Acct-Delay-Time, but they're rather old and had to do with Radiator 2.14 and MAXes. The manual seems to indicate that the default value of Acct-Delay-Time is 0, but as you can see from the accounting log the second stop record has a value of 60 which is exactly the 1 minute difference between stop records that we're seeing. In this a Radiator problem or a Total Control problem or should I be looking elsewhere. Thanks in advance. William Hernández ESS/PR Webmasters San Juan, P.R. Tel: 787-723-5000 Fax: 787-722-6242 -From the dictionary file-- ATTRIBUTE Acct-Delay-Time 41 integer -From the Accounting detail file--- Wed Aug 15 08:59:29 2001 User-Name = pijuan NAS-IP-Address = 208.249.78.12 NAS-Identifier = 208.249.78.12 Acct-Status-Type = Stop Acct-Session-Id = 35455064 Acct-Delay-Time = 0 Acct-Authentic = RADIUS Service-Type = Framed-User NAS-Port-Type = Async NAS-Port = 549 USR-Modem-Training-Time = 17 USR-Interface-Index = 1805 Chassis-Call-Slot = 3 Chassis-Call-Span = 2 Chassis-Call-Channel = 37 Unauthenticated-Time = 4 Calling-Station-Id = Called-Station-Id = 6419000 VPN-ID = 0 Modulation-Type = v90Digital Simplified-MNP-Levels = ccittV42 Simplified-V42bis-Usage = ccittV42bis Connect-Speed =
RE: (RADIATOR) Need clarification on AuthSelect with AuthColumnDef
Forgot to mention... the FIRST thing we tried using was the radmin.cfg file from our older radiator server, which was (and still is) working fine on that machine... it is AuthSelect select PASS_WORD,STATICADDRESS,TIMELEFT,\ NULL,FRAMED_NETMASK,FRAMED_FILTER_ID,\ MAXIDLETIME \ from RADUSERS where \ USERNAME='%n' and BADLOGINS 5 and \ VALIDFROM %t and VALIDTO %t AuthColumnDef 0,Framed-IP-Netmask,reply AuthColumnDef 1,Filter-Id,reply AuthColumnDef 2,Idle-Timeout,reply This exact config works on the old server, but on the new server the reply via radpwtst doesn't include the framed-ip-netmask (nor the filter-id, nor the idle-timeout) Thanks! Jay West -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jay West Sent: Thursday, October 18, 2001 3:16 PM To: [EMAIL PROTECTED] Subject: (RADIATOR) Need clarification on AuthSelect with AuthColumnDef Can't seem to get radiator 2.18.4 to pass the correct reply items back to the nas. We used the default radmin.cfg, and implemented the changes at the top that are listed in the comments for if you want to add things like Framed-IP-Netmask, Idle-Timeout, etc. According to the Docs, you can specify your OWN Authselect, and then your AuthColumnDef should start at 0, with 0 being the first item passed back AFTER the required first four items. However, this doesn't seem to work (ie. the easy example of how to add things like Framed-IP-Netmask doesn't work). This isn't a database problem or anything, because it does get the Framed-IP-Address correctly for each user, but there is no Framed-IP-Netmask in the reply (shown with radpwtst -trace). Has anyone else run into this, and what is the fix? I have read the docs on AuthColumnDef and feel like there's some piece that I'm missing. The LAST attempt I made I tried specifying everything in the reply rather than just the additions (according to the docs, this isn't necessary, but I was out of other ideas...) AuthSelect select PASS_WORD,\ STATICADDRESS,TIMELEFT,MAXLOGINS,FRAMED_NETMASK,FRAMED_FILTER_ID,\ MAXIDLETIME \ from RADUSERS where \ USERNAME='%n' and BADLOGINS 5 and \ VALIDFROM %t and VALIDTO %t AuthColumnDef 0,User-Password,check AuthColumnDef 1,Framed-IP-Address,reply AuthColumnDef 2,Session-Timeout,reply AuthColumnDef 3,Session-Timeout,reply AuthColumnDef 4,Framed-IP-Netmask,reply AuthColumnDef 5,Filter-Id,reply AuthColumnDef 6,Idle-Timeout,reply This gets me no Framed-IP-Netmask in the radpwtst -trace But Here is the stock radmin.cfg from the radiator distribution, and I get the same results... # You can add extra items to your RADUSERS table and make # Radiator take note of them with, for example: # AuthSelect select PASS_WORD,STATICADDRESS,TIMELEFT,\ #MAXLOGINS,FRAMED_NETMASK,FRAMED_FILTER_ID,MAXIDLETIME \ #from RADUSERS where \ #USERNAME='%n' and BADLOGINS 5 and \ #VALIDFROM %t and VALIDTO %t # AuthColumnDef 0,Framed-IP-Netmask,reply # AuthColumnDef 1,Filter-Id,reply # AuthColumnDef 2,Idle-Timeout,reply # note that the numbering of AuthColumnDef starts with the # field following the first 4 minumum and required fields. This also gets me no Framed-IP-Netmask in the radpwtst -trace The net effect is we want a stock config, but with the addition of FRAMED_NETMASK, FRAMED_FILTER_ID, and MAXIDLETIME Any ideas??? Jay West === 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) Tunnel-Client-Auth-ID and Tunnel-Server-Auth-ID
Hi Wim - On Thursday 18 October 2001 23:55, Wim Biemolt wrote: Hello Hugh, == From: Hugh Irvine You are defining the attributes as vendor specifics, but Radiator is complaining about standard attributes. Here is how to define them: ATTRIBUTE Tunnel-Client-Auth-ID90 string ATTRIBUTE Tunnel-Server-Auth-ID91 string I have also copied this mail to Mike so he can add these to the standard dictionary. hth Yes, adding the above to lines to my dictionary made the error messages go away. Thanks. So I guess (vendor ) really means not vendor specific. It actually means vendor 0, which is how the standard attributes are defined inside Radiator. I have also copied Mike on this mail and perhaps this message can be improved in the next release. thanks Hugh -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X. - Nets: internetwork inventory and management - graphical, extensible, flexible with hardware, software, platform and database independence. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) insert errors
Salut Jerome -
Merci pour ca!
I have copied Mike on this mail and he will consider the patch for inclusion
in the next release.
A+
Hugues
On Thursday 18 October 2001 20:00, Jerome Fleury wrote:
--On Tuesday, October 16, 2001 09:57:17 AM +0200 Jesús M Díaz
[EMAIL PROTECTED] wrote:
Hello,
i had the same problem too, but whit the pair 'nas-identifier/nas-port'.
i could solve it changing the AddQuery sentence at 'session sql' clause
from 'insert into ...' to 'replace into ...'.
the problem, as i could see, is when due an error or any other reason,
Radiator keeps a session entry but that sessions is not real yet.
regards
I don't really know if your problem is related to mine, but in our
configuration (big ISP, about 80 requests/s) we had a lot of duplicates. To
avoid this we patched Radiator to handle real duplicates.
For that, we match packets not only on packet ID, but on NAS IP and UDP
port Number (because some hosts like Lucent TNT have multiple ID space on
different port numbers). The patch is working perfectly.
Maybe this patch could be integrated into official release ?
Here it is for Radiator 2.18.4:
--8X cut here 8X--
*** Radius/Client.pm.old Wed Oct 3 15:28:46 2001
--- Radius/Client.pm Wed Oct 3 15:27:55 2001
***
*** 6,21
# Namethe host name the Client was created with
# HostPacked host address of the client
#
# In order to detect duplicate arrivals, we keep an array
! # of arrivals ($self-{RecentIdentifiers})indexed by the Radius packet
! # identifier (8 bits), concatenated with the packet type code.
# (The packet code is used because some NASs use different packet
# sequences for different request types)
# The value stored in each element of the array is the time
! # we last received
! # a packet with that identifier from this client.
! # If the time interval is
! # less than DupInterval, the packet is assumed to be
# duplicate, and is ignored
#
# Author: Mike McCauley ([EMAIL PROTECTED])
--- 6,23
# Namethe host name the Client was created with
# HostPacked host address of the client
#
+ # Patch by [EMAIL PROTECTED] (the old code did not use the IP
address):
# In order to detect duplicate arrivals, we keep an array
! # of arrivals ($self-{RecentIdentifiers})indexed by
! # the IP address of the host that sent the request,
! # the UDP port number (some hosts like Lucent TNT have multiple ID space
! # on different port numbers), the Radius packet identifier (8 bits),
! # concatenated with the packet type code.
# (The packet code is used because some NASs use different packet
# sequences for different request types)
# The value stored in each element of the array is the time
! # we last received a packet with that identifier from this client.
! # If the time interval is less than DupInterval, the packet is assumed to
be
# duplicate, and is ignored
#
# Author: Mike McCauley ([EMAIL PROTECTED])
***
*** 307,313
# accounting where the Acct-Delay-Time has changed, because
# the identifier will also have changed. Gag.
if (!$self-{NoIgnoreDuplicates}{$code}
! $self-{RecentIdentifiers}-{$nas_id . $code}[$p-identifier]
($p-{RecvTime} - $self-{DupInterval}))
{
if (!$is_reboot)
--- 309,315
# accounting where the Acct-Delay-Time has changed, because
# the identifier will also have changed. Gag.
if (!$self-{NoIgnoreDuplicates}{$code}
! $self-{RecentIdentifiers}-{$p-{RecvFrom} . $code}[$p-identifier]
($p-{RecvTime} - $self-{DupInterval}))
{
if (!$is_reboot)
***
*** 314,320
{
# Its a duplicate, log it and ignore it
my $id = $p-identifier;
! main::log($main::LOG_INFO, Duplicate request id $id received from
$nas_id: ignored);
$self-{Statistics}{radiusServDupAccessRequests}++,
$main::statistics{radiusAuthServTotalDupAccessRequests}++
if $code eq 'Access-Request';
--- 316,326
{
# Its a duplicate, log it and ignore it
my $id = $p-identifier;
! my ($udpPort, $udpAddr) = Socket::unpack_sockaddr_in($p-{RecvFrom}
! );
! my ($udpAddrPrint) = Socket::inet_ntoa($udpAddr);
!
! main::log($main::LOG_INFO, Duplicate request id $id received from
$udpAddrPrint($udpPort): ignored);
$self-{Statistics}{radiusServDupAccessRequests}++,
$main::statistics{radiusAuthServTotalDupAccessRequests}++
if $code eq 'Access-Request';
***
*** 327,333
else
{
# its
Re: (RADIATOR) AddToReply also in accounting?
Hi Wim - I have copied Mike on this mail and the manual will be clarified for the next release. Thanks for pointing out the inconsistency. regards Hugh On Friday 19 October 2001 00:04, Wim Biemolt wrote: Hola Mariano, Hello Hugh, == From: Hugh Irvine Yes Mariano is correct in what is shown below. Note that there may or may not be reply attributes in accounting responses. Wim is right in saying that they are usually empty, but there are some applications (usually proxy setups) that require reply attributes in accounting responses as well as in access accepts. As Wim points out, AddToReply(IfNotExist) can be used in both cases. And as Mariano shows below, Handlers can be used to deal with authentication and accounting separately. The solution of Mariano could work. But my greatest problem is that is see something which is not correct according to the reference manual. According to the reference manual AddToReply adds attributes *to Access-Accepts*. But as I understand it now this should be adds attributes to (all) replies. Just a minor detail. Cheers, -Wim -/- SURFnet === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message. -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X. - Nets: internetwork inventory and management - graphical, extensible, flexible with hardware, software, platform and database independence. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Block Time on RADMIN
Hello Suwat - The latest version of Radmin has support for per-user and per-service check and reply attributes. You should upgrade to Radmin-1.5. regards Hugh On Thursday 18 October 2001 22:05, Suwat Charoensakpanich wrote: Hello... I use RADMIN for manage user on MySQL.It's work ok.But I don't understand.Why RADMIN don't have some attribute check? .An attribute check is Block-Logon-From. I want to manage user with RADMIN. My issue : User can connect on Monday to Friday at 8:00 to 17:00 ( Block-Logon-From or Block-Logon-To or Time).If I config on a users file then it's ok.But on RADMIN haven't config that.Why? Please recommended me Best Regards, suwat.c __ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message. -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X. - Nets: internetwork inventory and management - graphical, extensible, flexible with hardware, software, platform and database independence. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Multiple Accounting Stop Records
Hello William - As mentioned in my previous email, the very first thing to do is find out what exactly is happening. In other words, fix the real source of the problem by finding out why the retransmissions are happening in the first place. Then, my suggestion would be to change to using an SQL database for your accounting and only log accounting stops. You can also use an AcctSQLStatement in the AuthBy SQL clause to make sure you only get a single copy (there was a posting about this a year or so ago - check the archive). In this scenario, the configuration file would look like this: # define AuthBy clauses . AuthBy SQL Identifier SQLAccounting . AccountingStopsOnly AccountingTable . AcctColumnDef . .. AcctSQLStatement . /AuthBy # define Handlers Handler Request-Type = Accounting-Request AuthBy SQLAccounting . /Handler Handler . /Handler The advantage of doing it this way is that you won't have any post-processing to do at all - it is all done automatically. Note that you can always keep a copy of the accounting records in a flat file too if you would like to keep an archive copy. hth Hugh On Friday 19 October 2001 06:46, William Hernandez wrote: Hello everyone, After some checking we've found out that the TotalControls cannot be configured to not retransmit accounting records. The problem is that we have these multiple stop records in the detail file which create a billing problem for us. Right now I run a perl script to cleanup the detail file, but I'm wondering whether the following will work. The idea is to only write to the accounting detail files the accounting start records and the accounting stop records that have an Acct-Delay-Time of 0. All other accounting requests would be ignored. Right now I use Handlers. In this setup I would replace each Handler in my current radius.cfg with 3 Handlers. This would be a one time pain, but I wouldn't have to run the perl script and everything would be right in the radius.cfg. Here goes: Handler Realm=domain.com Request-Type=Access-Request as before.with the AcctLogFileName line removed /Handler Handler Realm=domain.com Request-Type=Accounting-Request Acct-Status-Type=1 AcctLogFileName /var/log/radacct/detail /Handler Handler Realm=domain.com Request-Type=Accounting-Request Acct-Status-Type=2 Acct-Delay-Time=0 AcctLogFileName /var/log/radacct/detail /Handler Does it make sense? Do I need an AuthBy clause if I'm only handling Accounting-Request? Thanks in advance, William -Original Message- From: Hugh Irvine [mailto:[EMAIL PROTECTED]] Sent: Monday, August 27, 2001 7:43 PM To: William Hernandez; Radiator Subject: Re: (RADIATOR) Multiple Accounting Stop Records Hello William - What you are seeing is NAS retransmissions because the NAS has not received an Accounting-Response in reply to an Accounting-Request (or possibly a NAS bug). The radius retransmission timeout on the NAS must be set to 60 seconds if that is what you are seeing in the log file. Note that it is pretty simple to recognise the retransmissions simply by the fact that the Acct-Delay-Time is not 0. In other words, the first transmission of an accounting packet will have an Acct-Delay-Time of 0, the second will have an Acct-Delay-Time of whatever the radius retry timeout is set on the NAS, the third will have an Acct-Delay-Time of twice the radius retry timeout, etc. etc. The way to find out what is happening is to check a trace 4 debug from Radiator to verify that the first accounting packet in the series is indeed being replied to, and then use your favourite packet sniffer along the transmission path back to the NAS to verify whether the reply is getting back to the NAS. In our experience the vast majority of problems like this are the direct result of saturated links somewhere in the transmission path that cause packets to be dropped. hth Hugh On Tuesday 28 August 2001 04:04, William Hernandez wrote: We're having a problem with multiple accounting stop records. The stop records have exactly a 1 minute difference between them, ..i.e, a stop record at 09:00:00 is followed by another stop record at 09:00:01. We starting seeing these multiple accounting stop records about a month ago. This coincides with some changes we made to our systems, namely, upgrading to RedHat 7.1, upgrading to Radiator 2.18.1, and switching to TotalControl (HiperArc) NASes. I need help determining why we're getting there multiple stop records. Everything was working fine with Radiator 2.16 and with the Ascend Maxes we were previously using. I found some messages in the archives about Acct-Delay-Time, but they're rather old and had to do with Radiator 2.14 and MAXes. The manual seems to indicate that the default value of
Re: (RADIATOR) signal to NAS
Hello Lloyd - On Saturday 20 October 2001 18:13, lloyd dagoc wrote: hello, just wondering if RADIATOR can send a signal to NAS to disconnect a particular usercan RADIATOR do that? if yes , how? Radiator cannot do it directly, however if your NAS software supports the new radius Disconnect-Request, you can use radpwtst to send it. This subject has been discussed on the list previously, so do a search on the archive (www.open.com.au/archives/radiator). regards Hugh -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X. - Nets: internetwork inventory and management - graphical, extensible, flexible with hardware, software, platform and database independence. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
