Hello Aaron -
>
> I am working on a new installation at a client site. The client is using
> a mix of Ascend Max 4000 and TNT as NAS. We noticed that the NAS tried to
> send multiple requests to Radiator with a slightly different Acct-Delay-Time
> but same Session ID. The problem is that currently their existing billing
> system cannot handle duplicate records in the accounting log. When I read in
> the source code, I noticed this is a known problem, in particular:
>
> In Client.pm (near the section that handles DupInterval):
> [...]
> # BUG ALERT: this _wont_ catch retransmissions of
> # accounting where the Acct-Delay-Time has changed, because
> # the identifier will also have changed. Gag.
> [...]
>
> I have tried to modified the source code (by adding one more hash to
> store Session ID with NAS IP, port and status type as the key) to trap this
> particular situation. I am able to detect this situation. From the original
> comment in the source code it seems that accounting log will not be
> generated for duplicating requests. However, it seems that the accounting
> log is still written no matter what. Did there anyone here encounter the
> same problem? Am I looking at the wrong place of source code? I know that I
> can write another script to pre-process the accounting log before feeding it
> to their billing system but our client wants a cleaner solution (that fits
> inside Radiator). Any suggestions will be welcome.
>
This is one of the known limitations of the Radius protocol, in that the
specification says that retransmissions of accounting retries must contain an
accurate Acct-Delay-Time, hence the packet authenticator must change as well.
I think in the first instance you should check a trace 4 debug list from
Radiator to verify the timestamps on the accounting requests and the subsequent
accounting replies (typical response times are on the order of a millisecond).
If you are seeing duplicate accounting records, it may be because the
Radius timeouts on the NAS equipment have been set too short (5 to 10 seconds
is typical). The problem may also be due to a bug or other configuration issue
in the NAS.
Radiator does take a conservative approach to accounting records and will write
them all, with the expectation that keeping all of them is preferable to
potentially loosing any by accident.
Note that in your discussion above, you refer to duplicate packets, which are
not the same thing as retransmissions. Duplicates refer to *identical* packets
that have somehow been the result of network infrastructure problems.
hth
Hugh
--
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.
