Corneliu Rudeanu writes...
I was really surprised to see how HARC deals with the radius packet identifier.
RFC states as clear as posibile: "For retransmissions where the contents are identical, the Identifier MUST remain unchanged.".
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. -- Aaron Nabil - 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.