On Wed, Mar 08, 2000 at 07:03:28PM -0600, Mike Nerone wrote:
> Well, for the purpose of this issue, we have to assume that for one reason
> or another a duplicate packet did, in fact, arrive at Radiator's accounting
> port. That's the only way this concern even comes into play. After all, why
> build duplicate packet detection into Radiator unless it can detect
> duplicate packets.
>
> I really suspect I'm misunderstanding something here, so please explain it
> to me, because what I'm hearing is this scenario:
>
> 1. The only way Radiator sees a dup is if, for some reason, Radiator's ack
> packet doesn't make it back to the NAS, thereby causing a retransmission.
> 2. Any time the NAS retransmits, it's going to have a different
> Acct-Delay-Time (time has, after all, passed).
> 3. Any duplicate Radiator received will therefore have a different
> Acct-Delay-Time.
> 4. Radiator compares (a checksum of) the whole packet when checking for
> duplicates.
> 5. Therefore, Radiator will perforce fail to recognize the duplication of
> any accounting packets.
>
> I know I'm going to kick myself when I hear this. :)
>
That's how it works. I've try to make up a system for myself which
opens up the packets and stores stuff liked Account-Session-Id, username,
nas, nas port, session time. It can then checks when a duplicate packet
comes in to whether it matches the previously accepted stop packets - if it
matches the above items it ACKs it back to the NAS but internally discards it.
However, I ended up painted into a corner with some bugs my limited perl
skills didn't nail and gave it up.
[EMAIL PROTECTED]
===
Archive at http://www.starport.net/~radiator/
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
