RE: (RADIATOR) radiators duplicate detection (ClientIP+Identifier+?SourcePort?)
Hi Rainer,
As stated in the changelog for 3.6, Radiator no longer indexes on UDP
port. This is illustrated by the following code from Client.pm :
# its not a dup, save the id for later dup checking
$self-{RecentIdentifiers}-{$p-{RecvFromAddress}}-{$code .
$p-identifier} = $p-{RecvTime};
Seems like the comment block was not changed to reflect this new, not
RFC compliant, duplicate checking.
wkr
Arjan
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Hugh Irvine
Sent: Tuesday, September 30, 2003 12:36 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: (RADIATOR) radiators duplicate detection
(ClientIP+Identifier+?SourcePort?)
Hello Rainer -
Here is the comment block from Radius/Client.pm:
# 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
Does this answer your question?
regards
Hugh
On Tuesday, Sep 30, 2003, at 07:16 Australia/Melbourne, Rainer Huber
wrote:
Hi!
I've seen that radiator detects duplicate records depending only on
the identifier and the client IP:
If more than 1 Radius request from this Client with the same Radius
Identifier are received within DupInterval seconds, the 2nd and
subsequent are ignored.
Shouldn't be the Identifier, the ClientIP and the SourcePort the keys
for
duplicates?
The RFC 2865 says:
Identifier: The Identifier field is one octet, and aids in matching
requests and replies. The RADIUS server can detect a duplicate request
if it has the same client source IP address and source UDP port and
Identifier
within a short span of time.
Is it a mistake in the refmanual?
Regards,
Rainer
===
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.
NB: have you included a copy of your configuration file (no secrets),
together with a trace 4 debug showing what is happening?
--
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows, 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.
__
This inbound message to KPN has been checked for all known viruses by
KPN MailScan
(IV-Scan), powered by MessageLabs.
For further information visit: http://www.veiliginternet.nl
__
===
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) Unknown reply received
One possibility is that a reply from the server you proxy to arrives outside the timeout set in Radiator, i.e. a late packet. When the timeout period expires Radiator removes the packet from the queue and generates a new packet (or if it is the last try stops sending). Because there now is no matching packet in the queue for the late packet Radiator sees it as an unknown reply. Regards, Arjan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Lisa Goulet Sent: Tuesday, May 01, 2001 3:02 PM To: [EMAIL PROTECTED] Subject: (RADIATOR) Unknown reply received Hi all, I am seeing on an average about 20 per day, Unknown reply received messages from the server I'm proxying to. Does this number fall in the alarm category? Thanks, Lisa === 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. ***DISCLAIMER*** Deze e-mail is uitsluitend bestemd voor de geadresseerde(n). Verstrekking aan en gebruik door anderen is niet toegestaan. KPN N.V. sluit iedere aansprakelijkheid uit die voortvloeit uit elektronische verzending. This e-mail is intended exclusively for the addressee(s), and may not be passed on to, or made available for use by any person other than the addressee(s). KPN N.V. rules out any and every liability resulting from any electronic transmission. === 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) conditional logging
Hello, I was wondering whether it's possible to do some kind of conditional logging, with the AcctLogFileName. For example, would it be possible to say, that radiator should only log the accounting line (defined in AcctLogFileFormat), if Acct-Status-Type (or any other attribute) has a specific value? If so, how could I do this, and where could I find more information about it? See 6.15 in the manual, you could use something like this : Handler Acct-Status-Type="specific value" AcctLogFilename filename AuthBy yourusualhandler /Handler With yourusualhandler as identifier for the handler your using normally. Thanks, -Andy Regards Arjan ***DISCLAIMER*** Deze e-mail is uitsluitend bestemd voor de geadresseerde(n). Verstrekking aan en gebruik door anderen is niet toegestaan. KPN N.V. sluit iedere aansprakelijkheid uit die voortvloeit uit elektronische verzending. This e-mail is intended exclusively for the addressee(s), and may not be passed on to, or made available for use by any person other than the addressee(s). KPN N.V. rules out any and every liability resulting from any electronic transmission. === 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) DNIS Realm proxy
See 6.15 and 6.27, i.e. something like this : AuthBy RADIUS Hosteric.open.com.au Secret 666obaFGkmRNs666 Identifier radiusproxy1 /AuthBy handler Called-Station-Id="value" AuthBy radiusproxy1 /Handler Regards Arjan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of JC Sent: Monday, April 02, 2001 7:10 PM To: [EMAIL PROTECTED] Subject: (RADIATOR) DNIS Realm proxy hi everybody, I would like to setup a radius that can proxy based on dnis. Does radiator support this ? JC ***DISCLAIMER*** Deze e-mail is uitsluitend bestemd voor de geadresseerde(n). Verstrekking aan en gebruik door anderen is niet toegestaan. KPN N.V. sluit iedere aansprakelijkheid uit die voortvloeit uit elektronische verzending. This e-mail is intended exclusively for the addressee(s), and may not be passed on to, or made available for use by any person other than the addressee(s). KPN N.V. rules out any and every liability resulting from any electronic transmission. === 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) Fallback to flat file accounting - no reply
In earlier versions you should use an AuthByPolicy ContinueWhileIgnore. If a SQL-database fails Radiator cannot get a reply and ignores the request instead of rejecting it. Arjan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Hugh Irvine Sent: Friday, March 30, 2001 7:19 AM To: Janet N. del Mundo; [EMAIL PROTECTED] Subject: Re: (RADIATOR) Fallback to flat file accounting - no reply Hello Janet - In Radiator 2.18 you would use the "AcctFailedLogFileName ..." parameter directly. See section 6.26.15 in the Radiator 2.18 reference manual. hth Hugh At 8:11 +1000 01/3/30, Janet N. del Mundo wrote: Hi, I'm wondering if I'm using the correct AuthByPolicy to handle falling back from a SQL DB to a flat file for accoounting. Is this right? Handler Request-Type = Accounting-Request AuthByPolicy ContinueWhileReject AuthBy SQL AuthBy FILE Filename %D/detail.%y%m /AuthBy /Handler When I do a radpwtst, the accounting replies say 'No reply'. If I put this Handler clause in production, will it work if our SQL DB goes down? Will it send an 'OK' back to the NAS's? For testing purposes in my AuthBy SQL clause, I set the Timeout 10 and FailureBackoffTime 20. Also, I have a fake SQL DBSource to have it fall back to the flat file. # ./radpwtst -secret dork -user xx -password x -auth_port 2000 -acct_port 2001 -timeout 60 sending Access-Request... OK sending Accounting-Request Start... No reply sending Accounting-Request Stop... No reply Thanks, Janet -- _ Janet del Mundo Internet Administrator, Startec Global Communications 135 Chalan Santo Papa Agana, Guam 96910 Email: [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. -- 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. ***DISCLAIMER*** Deze e-mail is uitsluitend bestemd voor de geadresseerde(n). Verstrekking aan en gebruik door anderen is niet toegestaan. KPN N.V. sluit iedere aansprakelijkheid uit die voortvloeit uit elektronische verzending. This e-mail is intended exclusively for the addressee(s), and may not be passed on to, or made available for use by any person other than the addressee(s). KPN N.V. rules out any and every liability resulting from any electronic transmission. === 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) Restricting DefaultSimultaneousUse to a particular client
-- From: Mike McCauley[SMTP:[EMAIL PROTECTED]] Sent: Friday, February 23, 2001 2:06 PM To: [EMAIL PROTECTED] Subject:(RADIATOR) Restricting DefaultSimultaneousUse to a particular client Hi. I'm currently using Radiator in an environment where people are dialling in multiple times (ie sharing accounts). To prevent this, I inserted the DefaultSimultaneous clause, and that worked great. Our POP3 server however uses Radius for authentication, and the POP3 retrievals were rejected because of an apparent attempt to authenticate twice. Is there any way to restrict the Simultaneous parameter to a specific NAS ? Khetan Gajjar. --- [EMAIL PROTECTED] One way to do it is by using a handler to catch the specific NAS, i.e. something like : Handler NAS-IP-Address = . ... /Handler wkr Arjan ***DISCLAIMER*** Deze e-mail is uitsluitend bestemd voor de geadresseerde(n). Verstrekking aan en gebruik door anderen is niet toegestaan. KPN N.V. sluit iedere aansprakelijkheid uit die voortvloeit uit elektronische verzending. This e-mail is intended exclusively for the addressee(s), and may not be passed on to, or made available for use by any person other than the addressee(s). KPN N.V. rules out any and every liability resulting from any electronic transmission. === 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.
