Compare Technical Support | Silvercreek SNMP Test Suite

Home

Compare Technical Support

Customer Question:
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.
My agent FAILS this test.

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

It seems to me in both cases, empty contextEngineIDs are being sent, so the agent should respond the same way in both situations. 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", itshould 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

RFC 3412: 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 registered for this request or notification:

2) If no application has registered 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

Customer Follow up Question:
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 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) registered for the "empty contextEngineID". Customer Follow up Question:
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. InterWorking Labs Answer:

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