usmAddUserName v usmAddUser

[Frank Fock]

Hi,

Please take a look at the latest SNMP++, which is version 3.2.1b.
Jochen has cleaned up the code in many areas, in particular,
the USM is now more object oriented. Thus, usmAddUser is now
deprecatec and should no longer be used. Instead the following
code should be used:

    USM *usm = mpGetUsm();
    usm->add_usm_user(..);

In order to add a user with localized keys (instead of pass phrases),
use:

    USM *usm = mpGetUsm();
    usm->add_localized_user(..);

Hope this helps.

Best regards,
Frank


D. R. Evans wrote:
> Just when I think I understand something, it seems like when I look a bit 
> deeper it turns out that I don't understand it at all. Sigh....
> 
> Starting with the receive_trap and snmpInform examples as they are 
> supplied, the code works fine.
> 
> Both of these, I notice, use usmAddUserName to tell the engine about the 
> existence of a user. The actual source code in AddUserName makes reference 
> to a usmUserNameTable, whose purpose isn't entirely clear -- what is clear, 
> though, is that it is different from a regular usmUserTable.
> 
> Anyway, I want to be able to add a user when I have the following 
> information at my disposal for both the initiator of an inform and for the 
> responder to the inform (i.e., in pre-v3 parlance, the agent and the 
> manager):
> 
> engineID, engineIDBoots, engineIDTime, usmUserName, authorization_key, 
> privacy_key.
> 
> With this information, it seems that one cannot simply follow the examples 
> and call usmAddUserName(), because that uses passwords instead of keys. 
> Instead, it looks like one ought to be able to substitute a call to 
> usmAddUser(), since that function uses keys instead of passwords.
> 
> So it seems reasonable, as a first stab hack-ish attempt at performing an 
> authenticated exchange, to put something like this into both 
> receive_trap.cpp and snmpInform.cpp:
> 
> status = usmAddUser((unsigned char*)<other side's engineid>,
>                     strlen(<other side's engineid>),
>            (unsigned char*)"meauthnopriv", strlen("meauthnopriv"),   
>            (unsigned char*)"meauthnopriv", strlen("meauthnopriv"),
>            SNMPv3_usmHMACMD5AuthProtocol, 
>            (unsigned char*)"meauth",
>            strlen("meauth"),
>            SNMPv3_usmNoPrivProtocol, (unsigned char*)"", strlen(""));
> 
> This seems like it should set the securityName and usmUserName to 
> "meauthnopriv", the authentication key to "meauth" and the authentication 
> protocol to MD5.
> 
> BUT if one now sends an inform, the response that comes back produces the 
> following output:
> 
> scoped PDU:
> 30 82 00 33  04 0C 72 65  63 65 69 76  65 5F 74 72
> 61 70 04 00  A8 21 02 02  03 E9 02 01  00 02 01 00
> 30 82 00 13  30 82 00 0F  06 0A 2B 06  01 06 03 0F
> 01 01 03 00  41 01 02
> Parsing contextEngineID with length = 0xc
> Parsing contextName with length = 0x0
> ASN parse error (Wrong Type. Not an integer)
> ***Receiving a ReportPDU ***
> mp finished (OK)
> Received a report pdu: SNMPv3: USM: Unknown SecurityName
> Oid = 1.3.6.1.6.3.15.1.1.3.0
> Value = 3452816845
> 
> It's not clear whether the "ASN parse error" is really meaningful, but it 
> is clear that the "Unknown SecurityName" is a problem.
> 
> I have played with this for several hours now, trying variations on the 
> theme described above. These variations all seem to fail in predictable, 
> sensible ways. But I don't understand why the code I originally used fails 
> with the "Unknown SecurityName" error.
> 
> So does anyone know the correct way to add a user when one has keys but no 
> passwords?
> 
>   Doc Evans
> 
>