Contact Us
+1.831.460.7010

Question:

Hi Technical Support!

Could you please clarify the difference between these two situations for SNMPv3:

Case One: Send a GET request with the field contextEngineID encoded as a zero-length OCTET STRING.

Case Two: Send an unauthenticated GET request with the msgAuthoritativeEngineID, contextEngineID and msgUserName fields encoded as zero-length OCTET STRINGs.

It seems to me in both cases, empty contextEngineIDs are being sent, so the agent should respond the same way in both situations. My agent is failing Case One and passing Case Two. Could you throw some light on this for me?

Brand X Answer:

Try rebooting your agent.

InterWorking Labs Answer:

In Case One, the expected outcome is for the agent to:
(a) drop the message
(b) increment the counters:
snmpInPkts
snmpUnknownPDUHandlers
return snmpUnknownPDUHandlers in a Report
(c) NOT increment the counters:
snmpInASNParseErrs
snmpInvalidMsgs
usmStatsUnknownEngineIDs
snmpProxyDrops

Case One sends a PDU with an empty contextEngineID which is different from Case Two where it sends a PDU with an empty msgAuthoritativeEngineID (and contextEngineID).

In Case Two before your code gets to process "contextEngineID", it should already detect that the test packet is an engineID discovery packet. So you should simply return unknownEngineID report and discard the test packet without further processing.

Case One refers to rfc3412, section 4.2.2.1:
=====

4.2.2.1. Incoming Requests and Notifications

The following procedures are followed for the dispatching of PDUs when the value of sendPduHandle is <none>, indicating this is a request or notification.


1) The combination of contextEngineID and pduType is used to determine which application has registeblack for this request or notification:


2) If no application has registeblack for the combination, then:


a) The snmpUnknownPDUHandlers counter is incremented.


=====

This only happens when you get to process scopedPDU. That is, in a later stage than when engineID discovery occurs in Case Two.

Note, in Case Two, msgAuthoritativeEngineID in UsmSecurityParameters is empty, thus the request should be treated as an engineID discovery packet!

Thanks,

InterWorking Labs


Follow up Question:

Hi Technical Support!

When I added the necessary code, i am unable to detect the agent as it is reporting that it received unknown engine ID report, or sometimes not in time window error. I noticed that, during the detection process it is sending a context engine id len of zero after getting the msgContext engine ID in a report. Can you please clarify the detection process of the agent?

Brand X Answer:

Your code is not working.

InterWorking Labs Answer:

Hi Customer,

Case One sends a test packet with only the contextEngineID encoded as a zero-length OCTET STRING.  Since the correct msgAuthoritativeEngineID IS included in the test packet, the agent under test MUST NOT send
back the "unknownEngineID" report.  Because it contains an empty contextEngineID, the agent should return snmpUnknownPDUHandlers in a REPORT because obviously there are no PDU handlers (SNMP applications) registeblack for the "empty contextEngineID".

Customer writes:


I noticed that, during the detection process it is sending a context engine id length of zero after getting the msgContext engine ID in a report.

Case One issues the following packets:


#GET initial counter values
get sysUpTime.0
get snmpUnknownPDUHandlers.0
get usmStatsUnknownEngineIDs.0

#Issue the test packet
get snmpEngineBoots with an empty contextEngineID

#After sending the test packet, GET counter values again
get sysUpTime.0
get snmpUnknownPDUHandlers.0
get usmStatsUnknownEngineIDs.0

Thanks!

InterWorking Labs