https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2426
LEGO <luis.ontanon@xxxxxxxxx> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |luis.ontanon@xxxxxxxxx
--- Comment #3 from LEGO <luis.ontanon@xxxxxxxxx> 2010-03-01 14:43:15 PST ---
I don't get it...
RFC 3414 defines
usmUserEntry OBJECT-TYPE
SYNTAX UsmUserEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "A user configured in the SNMP engine's Local
Configuration Datastore (LCD) for the User-based
Security Model.
"
INDEX { usmUserEngineID,
usmUserName
}
::= { usmUserTable 1 }
where :
" INDEX {usmUserEngineID, usmUserName} " means that the combination of
usmUserEngineID + usmUserName is unique
which BTW is exactly what the code does.
On the other hand, the example you provide effectivelly overwrites the entries
several times.
e.g.
11111111,authusermd5des,MD5,authusermd5despw,DES,authusermd5despw
and
11111111,authusermd5des,MD5,authusermd5aespw,AES,authusermd5aespw
actually share the very same key (11111111,authusermd5des) so the two
UsmUserEntry(s) actually get overwritten.
the BUG here resides in the fact that two entries in the same table that share
the very same key are accepted without notifying an error. A fix for this might
be coming soon.
BTW this is *COMPLETELY* different than the problem described in Bug 2703. so
the two bugs aren't dups.
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
