Even without any packets being lost, the protocol itself contains inherent
race conditions and other possibly error states that makes control via
RADIUS packets alone a faulty proposition from the start. I've explained
this here many, many times in detail so I won't do it again.
>I will not argue with you as to whether or not the PM3 is not sending stop
>records. I KNOW that we are not receiving them occasionally. Whether the
If it is not connected to the known bug I mentioned (MP and Port-Limit) then
by all means report it. Until we can find evidence of a real problem,
and then find the actual problem itself, there isn't anything we can do.
>The current solution to every RADIUS problem seems to be "wait for RADIUS
>ABM". But my understanding of accounting tells me that the only source of
>accounting is from start and stop records generated from the Portmaster.
Cistron RADIUS and RADIUS ABM also use SNMP to backstop RADIUS when used
for simultaneous login control. This plugs the holes inherent in the
RADIUS protocol. (The holes aren't a 'bug' - they are deliberate. RADIUS
was designed with different objectives, which are in conflict with the
resource management objective.)
>Will the new RADIUS ABM software send an "acknowledgment" packet back to
>the Portmaster to confirm the packet was received? And will the Portmaster
You should read the RFCs. This is how ALL RADIUS works. The START/STOP
packet is sent, and the server sends an ACK. If the ACK is not received,
the NAS resends it. This is how it has always been.
I believe with our implementation we'll try the primary. If it fails
we backoff and keep trying the primary for 10 minutes, or until there
are 75 packets cached for retransmission, then we will fail over to the
secondary server. Off hand I don't recall what happens if there is no
secondary. The reason is that Accounting data is not considered time
sensitive while Authentication and Authorization is. It is considered
better to get the Accounting data to log on the primary to keep it in
one location, and it can afford to wait a little while. While auth needs
an answer immediately.
But that assumes a 100% bug free environment - if the server ACKs a packet
and then fails to log it, it of course will not be resent. If the NAS
drops a packet and fails to retransmit for any reason it will be lost.
It is certainly possible that one or both of the bugs exist, but they
have never been spotted. PortMasters routinely retransmit packets, so
if that is a problem it has to be very rare and very sporadic. And I've
not seen any evidence of a server failing to log a packet it ACKs. It
could even come from an underlying OS issue where the file write fails
but the server is unaware.
>packets have been sent? To me, this type of verification is the ONLY way
>that accounting can be done reliably.
Which is why that is how it works.
>BTW, when will we be able to get more information on RADIUS ABM, including
>release date. If the above "fix" is not in the software, we must start
The plan is still a late 1Q98 release AFAIK, so I expect more details
will become public in the weeks before FCS.
-MZ
-- Lucent Remote Access Division - Chair, Department of Interstitial Affairs Phone: 800-458-9966 510-737-2100 FAX: 510-737-2110 megazone@livingston.com For support requests: support@livingston.com <http://www.livingston.com/> Snail mail: 4464 Willow Road, Pleasanton, CA 94588 - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe portmaster-users' in the body of the message.