https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2703
--- Comment #4 from LEGO <luis.ontanon@xxxxxxxxx> 2010-03-02 21:26:39 PST ---
Here's how it works (or how it should work):
- Upon startup (launch) the usm table is read in its entirety and copied into
the config table.
- the config table can has two types of entries
- localized (those with a given engineId)
- unlocalized (those with no engineId)
- localized entries get straight into the working table (a cache) before
processing any packet (the keys, that are the result from an operation between
the passwd and the engineId, get computed as part of the localization)
- unlocalized entries are kept as such
- upon "reception" of a packet the table of localized entries is searched
- if there's a match (on engineId+username) the keys of the (localized)
entry are used to attempt auth+decryption.
- if there's no match the unlocalized entries are scanned to look for a
matching username
- if an unlocalized entry matches (username) it gets "localized" (the
keys are computed) and the localized entry is copied to the cache and then
decryption is attempted. (the localization happens only once per capture file)
-if no match was found neither in the localized entries (username+engineId)
nor in the unlocalized ones (username only) the packet does not get decrypted.
====
given that it is likely that the bug was not in the SNMP code but in the code
used to handle config tables (User Accessible Tables = UAT) which is used by
more modules in wireshark, and it got fixed when noticed for another table (UAT
code is quite complex so it was buggy in the beginning).
Being the original author of both the SNMP-USM implementation and UAT code I'm
the one to blame for this behavior.
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
