Anyone else have any views about this?
---------- Forwarded Message ----------
Subject: BOUNCE [EMAIL PROTECTED]: Non-member submission from [Jerome
Fleury <[EMAIL PROTECTED]>]
Date: Wed, 23 Oct 2002 04:09:37 -0500
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
>From [EMAIL PROTECTED] Wed Oct 23 04:09:36 2002
Received: from mail.libertysurf.net (mail.libertysurf.net [213.36.80.91])
by server1.open.com.au (8.11.0/8.11.0) with ESMTP id g9N99ZC15723
for <[EMAIL PROTECTED]>; Wed, 23 Oct 2002 04:09:36 -0500
Received: from sauron.eng.freesbee.net (212.129.4.220) by
mail.libertysurf.net (6.5.026) id 3DB4DCD800089BBD for [EMAIL PROTECTED];
Wed, 23 Oct 2002 16:03:19 +0200 Date: Wed, 23 Oct 2002 16:03:18 +0200
From: Jerome Fleury <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Event-Timestamp patch
Message-ID: <[EMAIL PROTECTED]>
X-Mailer: Mulberry/3.0.0a4 (SunOS/SPARC)
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature";
boundary="==========46901052=========="
--==========46901052==========
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Hello there,
I provide here a small (but useful) patch. This one allows to use the=20
Event-Timestamp accounting attribute sent by some NAS (especially Cisco=20
ones in later releases) instead of having to calculate it. (=3Drecvtime -=20
acct_delay)
This patch performs a small check: if the calculated timestamp and the NAS=20
timestamp differ for more than 300s (this is arbitrary), then we assume=20
that the server and the NAS are not synchronized, so it fallback to the=20
calculated timestamp (default).
Why did we use this ? Because the timestamp sent by the NAS looks much more =
reliable than the calculated one. As of a consequence, it performs better=20
in duplicate finding.
This code should probably be cleaned, maybe "config-variabled", but I hope=20
it will be integrated in futures releases.
--
Jerome Fleury Tiscali/LibertySurf/WC
Network Engineer Tel/Fax: +33 1 45082314
--------------------------------------------
*** Handler.pm.bak Mon Oct 21 12:34:37 2002
--- Handler.pm Wed Oct 23 12:46:20 2002
***************
*** 204,214 ****
{
# Add a pseudo attribute for the Timestamp
# (adjusted by Delay-Time)
# Some modules (AuthSQL) and logfile scripts rely on it
! $p->add_attr('Timestamp',
! $p->{RecvTime}
! - int=20
$p->getAttrByNum($Radius::Radius::ACCT_DELAY_TIME));
# Log the packet
my $status_type =3D $p->getAttrByNum
($Radius::Radius::ACCT_STATUS_TYPE);
--- 204,231 ----
{
# Add a pseudo attribute for the Timestamp
# (adjusted by Delay-Time)
# Some modules (AuthSQL) and logfile scripts rely on it
! # patch by Jerome Fleury <[EMAIL PROTECTED]>:
! # rely on Event_Timestamp attribute if present
! my $timestamp;
! $timestamp =3D $p->{RecvTime} - int=20
$p->getAttrByNum($Radius::Radius::ACCT_DELAY_TIME);
! # this patch uses Event-Timestamp if it exists
! if (defined=20
$p->getAttrByNum($Radius::Radius::ACCT_EVENT_TIMESTAMP)) {
! # we use arbitrary 300s of clock difference to check=20
attribute reliability
! if (abs($timestamp -=20
$p->getAttrByNum($Radius::Radius::ACCT_EVENT_TIMESTAMP) > 300)) {
! # NAS clock is not synchronized with the server,=20
let's use server timestamp, log a warning
! $self->log($main::LOG_WARNING, "$nas_id clock not=20
synchronized with server!");
! $p->add_attr('Timestamp', $timestamp);
! }
! else {
! # Event_Timestamp looks correct, let's use it
! $p->add_attr('Timestamp',=20
$p->getAttrByNum($Radius::Radius::ACCT_EVENT_TIMESTAMP));
! }
! }
! # we don't have Event_Timestamp attribute
! else { $p->add_attr('Timestamp', $timestamp); }
!
# Log the packet
my $status_type =3D $p->getAttrByNum
($Radius::Radius::ACCT_STATUS_TYPE);
-------------------------------------------------------
*** Radius.pm.bak Mon Oct 21 12:33:55 2002
--- Radius.pm Mon Oct 21 12:34:25 2002
***************
*** 114,117 ****
--- 114,118 ----
$Radius::Radius::ACCT_OUTPUT_PACKETS =3D 48;
$Radius::Radius::ACCT_TERMINATE_CAUSE =3D 49;
+ $Radius::Radius::ACCT_EVENT_TIMESTAMP =3D 55;
$Radius::Radius::CHAP_CHALLENGE =3D 60;
$Radius::Radius::NAS_PORT_TYPE =3D 61;
--==========46901052==========
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (SunOS)
Comment: For info see http://www.gnupg.org
iD8DBQE9tqwnnLJOfUlJE3wRAtVgAJ43LNxuEMIkHOFVTTUjSAn/5Z2RGACeMZlz
enLHsRQjIBxYnQcPvRHj8aA=
=E7Pt
-----END PGP SIGNATURE-----
--==========46901052==========--
-------------------------------------------------------
--
Mike McCauley [EMAIL PROTECTED]
Open System Consultants Pty. Ltd Unix, 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, EAP, TLS,
TTLS etc on Unix, Windows, MacOS etc.
===
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.
