Re: 5.6.1.pre1 released for testing

[Claus Klein]

Hi Wes,

thanks for you response.


Both fails with trunk version without my changes on my macbook.

See too my comments below.

With regards,
Claus

I send you my updated patch and one changed test script. I also add a new one.

engineID-v3trap.diff
Description: Binary data

T058agentauthtrap7_simple
Description: Binary data

T058agentauthtrap8_simple
Description: Binary data

On 07.12.2010, at 00:02, Wes Hardaker wrote:

Your test works as expected in the trunk right now and the 5.6 branch
right now.  So I think you have something else going on with your code
that you've likely modified?

I work with branch 5.4 and trunk version.  2 of my tests fails!
Without my changes, the agent dumps every time


The worst cast is to use a non existing usm user!

while sending a v3 traps after configuring the trap target via the MIB, not the configuration file.

I think that's fine if we added a else{} block stating that an empty
engineID was found as a counter debug statement.

Mine:
  +          if (engineID) {
  +              DEBUGMSGHEX(("usm", engineID, engineIDLen));
  +          } else {
  +              DEBUGMSGTL(("usm", "Empty EngineID"));
  +          }

OK that is better, I agree.

Note, however, that DEBUGMSGHEX actually should work just fine if passed

a null pointer.  I'm not suggesting it's wise to do, but as long as
engineIDLen is actually also 0 nothing bad should happen.  Now, if

though.

engineIDLen > 0 then things could get weird. I'd rather fix DEBUGMSGHEX

Yes, but the engineIDLen is not 0, see below

For agent_trap.c: the PDU engineID is set internally to the library from

the session engineID.  Not only that, but if you *don't* set session

be set in the session (though it could be set in the PDU too, it's
easier to leave it up to the library).

engineID then internally to the library probing will be done, which you don't want. So the code is correct as is. The securityEngineid should

Index: agent/agent_trap.c
===================================================================
--- agent/agent_trap.c  (revision 19724)
+++ agent/agent_trap.c  (working copy)
@@ -930,7 +930,9 @@

             len = snmpv3_get_engineID(tmp, sizeof(tmp));
             memdup(&pdu->securityEngineID, tmp, len);
-            sess->securityEngineIDLen = len;
+            //XXX sess->securityEngineIDLen = len;

+            pdu->securityEngineIDLen = len;
         }

         result = snmp_send(sess, pdu);

The main problem is that the pdu->securityEngineID is filled, but the sess->securityEngineIDLen is updated! + //FIXME: pdu was filled, not sess! So we should set the right length! ck

You said there was two NULL issues you were fixing, but I only see one
in your patch unless you're referring to the memdup possibly failing
(which would be from a malloc failure).

Yes, I changed too this to prevent a core dumps while sending traps.



This hack should not needed if you fix agent/agent_trap.c like above.

Index: agent/mibgroup/snmpv3/usmUser.c
===================================================================
--- agent/mibgroup/snmpv3/usmUser.c     (revision 19724)
+++ agent/mibgroup/snmpv3/usmUser.c     (working copy)
@@ -104,6 +104,13 @@
     oid            *indexOid;
     int             i;

+    if (uptr->engineIDLen && !uptr->engineID) {
+        snmp_log(LOG_ERR,

+            uptr->name, uptr->engineID, uptr->engineIDLen);

+    }
+
     *length = 2 + uptr->engineIDLen + strlen(uptr->name) + prefixLen;
     indexOid = (oid *) malloc(*length * sizeof(oid));
     if (indexOid) {


------------------------------------------------------------------------------
What happens now with your Lotus Notes apps - do you make another costly 
upgrade, or settle for being marooned without product support? Time to move
off Lotus Notes and onto the cloud with Force.com, apps are easier to build,
use, and manage than apps on traditional platforms. Sign up for the Lotus 
Notes Migration Kit to learn more. http://p.sf.net/sfu/salesforce-d2d
_______________________________________________
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

But this quikfix has the site effect to add a new usm user to the usmUserTable with emtpy engineID while sending the 1. trap! + "usm_generate_OID(name=%s, ID=%p, IDlen=%d) assert(!uptr- >engineIDLen || (uptr->engineIDLen && uptr->engineID)) failed!\n", + uptr->engineIDLen = 0; // FIXME: hack to continue without engineID!