Contact Us

Is your app or device ready for deployment?
It can be.

Uncover performance, compliance, and operational issues prior to deployment.


Watch Overview



network emulation, Test you apps under all network conditions


Network Emulation


Test your app under all network conditions—3G/4G, satellite, WAN, cloud—in your lab.

network protocol testing,


Protocol Testing


Are the network protocols implemented properly and securely, conforming to the specs, in your app or device?




Test your app or device under all network conditions – from the routine to the extreme. Automate a wide variety of network conditions from 3G/4G to Cloud to WAN to Satellite to Internet. Uncover performance and operational issues prior to deployment.

Learn More



Finding and fixing software defects constitutes the largest expense for the software industry. Learn why line speed testing isn’t enough and the importance of functional testing!

Learn More



Trial deployments are expensive and yield limited data. Learn how to properly characterize your application or device performance prior to deployment.

Learn More

View More Papers


"Apple uses Maxwell to emulate all varieties of customer networks and access points — from limited network bandwidth to extreme latency to packet drops.

By testing our products with Maxwell prior to deployment, we ensure that customers have a solid experience when they get new Apple software or hardware in their hands."

— Dmitry Halavin, Apple Inc.


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:
return snmpUnknownPDUHandlers in a Report
(c) NOT increment the counters:

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
===== 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!


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


InterWorking Labs


Over 1,000 organizations and 6,500 network professionals trust IWL.