Possible solution:
---------------------------
Frankly I'm not familiar enough with Net-SNMP inner-workings to be able
to identify the root cause of this behavior.
Anyway, I got a simple and seemingly harmless solution to offer:
In get_target_sessions(), when creating a new session, we can set the
session's SNMP_FLAGS_USER_CREATED,
this would later on prevent the user from being updated form the
session. (it works for informs)
Previous code section:
==============
if (param->mpModel == SNMP_VERSION_3) {
thissess.securityName = strdup(param->secName);
thissess.securityNameLen =
strlen(thissess.securityName);
thissess.securityLevel = param->secLevel;
thissess.securityModel = SNMP_SEC_MODEL_USM;
...
-----------------------------
New code section:
===============
if (param->mpModel == SNMP_VERSION_3) {
thissess.securityName = strdup(param->secName);
thissess.securityNameLen =
strlen(thissess.securityName);
thissess.securityLevel = param->secLevel;
thissess.securityModel = SNMP_SEC_MODEL_USM; // Avaya fix
// Seeting the SNMP_FLAGS_USER_CREATED ensures
// that later on the related User will not be changed.
// It assumes that for sending out an Inform, an appropriate user
// must be configured.
thissess.flags |= SNMP_FLAGS_USER_CREATED; // Another Avaya fix.
...
-----------------------------
I still have to test scenario where we change a user's auth parameters
(via SNMP sets),
I don't except any issues there.
Please review this solution, does it make sense to you?
Thanks,
Erez.
________________________________
From: Erez
Sent: Tuesday, June 19, 2007 8:53 PM
To: '[email protected]'
Subject: Possible BUG sending informs with SHA authenticaiton
Hi,
Background
-------------------
I'm using net-snmp 5.3.1 and trying to use the snmpTargetMIB to send out
informs.
Problem
------------
When sending out informs with users that have SHA authorization,
the informs fail authorization on the receiver side.
Analysis:
---------------
- Sending informs with users that have MD5 authorization works fine.
- I've added a print in usm_get_user_from_list() that shows me the
authProtocol of the fetched user,
and I can see that at some time after the engineProbe is sent the
authProtocol of the user changes from SHA to MD5.
- I concluded that it is caused by a call to create_user_from_session()
(I don't yet know exactly which call, there are several),
and the session has a default value of MD5, so it overrides the SHA
that is in the user.
Then later the packet is sent with the wrong
Question:
-------------
Can someone give me a hand here? ( it's getting really complicated to
debug this...)
Thanks,
Erez.
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Net-snmp-coders mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
