https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4096
Stipe Tolj <stolj@xxxxxxxxxx> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |stolj@xxxxxxxxxx
--- Comment #3 from Stipe Tolj <stolj@xxxxxxxxxx> 2012-08-17 10:14:04 PDT ---
Hi all,
I can confirm what Armen has reported some years ago. The RADIUS PDU
declaration of duplicates is "wrong".
IMO, we need to put the source IP, UDP port, RADIUS PDU identifier *AND* the
RADIUS PDU authenticator as a key constraint that the PDU is really a
duplicate.
Attached is a sample of a GGSN loading tool the simulates high-load RADIUS
accoutntping PDUs going to our Kannel-CG RADIUS server. While we see in the
sample that the RADIUS server is responding to the RADIUS request PDUs with
specific identifier 236, we still see Wireshak declaring the "next" req/resp
pair as duplicate. Which seems to be the case if a specific time limit isn'
reached yet. That's ok, but if we look into the RADIUS PDU details we see that
it is a semantically different PDU, just using the "low-space" same ID for a
next PDU.
When comparing the RADIUS PDU authenticator, we would know that and could avoid
declaring the PDU being a duplicate.
Stipe Tolj
Kannel Software Foundation - http://www.kannel.org/
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
You are watching all bug changes.
