On Tue, 12 Oct 1999, Aaron Nabil wrote:
Corneliu Rudeanu writes...
Yet watching (monitor radius) the id-s of the packets being retransmited I found that hiperArc (4.2.29) assigns diferrent id for the packets being re-sent to radius server for the same accounting request.
Hah! It's much better than that! (Note the date, too!)
From: Aaron Nabil <nabil@spiritone.com> Subject: (usr-tc) HiperArc BUG, doesn't increment identifier after re-transmit Date: 14 Jun 1998 16:58:15 -0700 (PDT)
The HiperArc has a nasty Radius bug.
If a packet get lost in transit or for some other reason is never acknoweldged, the HiperArc increments the identifier and tries sending it again after the timeout period.
But later, when it comes time to send another request, it has "forgotten" that it previously incremented the identifier and merrily uses the last one again!
Not only does it incorrectly increment the identifier, it then goes on to re-use the same identifier again later! Yes, this is so incredibly broken it's not even imaginable that it hasn't been fixed. But it hasn't.
My question: how is suposed a Radius server to identify the duplicates?
The Radius server is supposed to contact the System Administrator and get him to purchase products from a vendor that knows how to read a RFC, or, failing that, at least fixes problems when they are pointed out to them.
Thanks for the prompt response. And my apollogies for re-opening the subject. I do agree with you: things should be good. Yet things are bad. I guess I am not the only one looking for a solution. Does some kind of checksum over acct-session-id, username, status-type worth any thrust? Even this kind of 'hand made' solution would help me. Any advice? TIA, Corneliu Rudeanu - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.