Accommodating more real-world malformed traps

Hi. I appreciate that SNMP4J makes some accommodations for some vendor bugs, e.g. SNMP4JSettings.setAllowSNMPv2InV1(). I’ve run into other scenarios with my customers that have required some custom code. I want to share one, in case you want to add support in the official code. (The following refers to code in the latest SNMP4J version 3.4.2.)

[Edited here to remove an “uptime field length correction” suggestion… Just heard the vendor was able to fix that bug.]

More than once, a customer has deployed devices with identical engine IDs. For v3 traps, this leads to correct, but very odd-looking behavior. For example: SNMP4J will accept a trap from the first sending device, but then if a device with a higher boot# sends a trap, the first device will be ignored from then on. Then if the customer reboots the first device a few times, it may achieve the higher boot#, so the second device is then ignored. Rebooting the SNMP4J app (clearing the ID/time history) adds to the confusion. It’s not easy for a customer to debug, and as you can imagine, the app gets blamed. For customers with thousands of devices, or with political/corporate walls between the NOC and the equipment admins, it may be impractical to fix the engine IDs. Apparently, “DX Spectrum” NMS has adapted to this reality by ignoring engine ID/time issues. We could address this in SNMP4J by editing to add code at line 691 to re-write the result of checkTime(), right before the switch statement that evaluates the result:

status = SnmpConstants.SNMPv3_USM_OK;

It could be done more efficiently, but this leaves the timeTable’s operations in tact, in case this “fix” is later disabled by some flag during runtime.

It would be nice if this could be switched via a SNMP4JSettings option. In addition, maybe some error logging could be preserved, or counters added, or better yet, a special listener/hander API existed to remind SNMP4J users that something non-standard is happening… A listener API would provide an opportunity to log the offending traps, ideally in PCAP format. (I could send you a custom MessageDispatcher that writes bad packets to a PCAP log file, if that’s useful to you.)

Of course, I do understand why you may want to ignore this idea, since the problem does not originate from SNMP4J, and it would mean essentially processing corrupt data. There is some precedent set with the setAllowSNMPv2InV1 option, but maybe that’s different. Anyway, I appreciate your consideration.

Yeah, duplicate engine IDs are like a pest. Only few vendors seem to ever read the SNMPv3 RFCs - although they are very well written and not that long :wink:

Because this engine ID problems do not want to disappear even after more than 20 years, I will add a special listener interface in SNMP4J (most likely in version 3.5.0) that will allow to actively handle engine time problems. This is quite better (in my opinion) instead generally ignore engine time issues - because this will allow replay attacks in general.

1 Like

Your plan sounds perfect. Thank you. (Wow, 20 years… Time certainly flies while we’re coding.)

Is the “engine ID problem listener” feature you proposed above still on your development roadmap? (It looks like version 3.5.1 was a pretty big release, so I’m not too surprised that feature wasn’t implemented yet. Just want to confirm if it still planned.)

Yes, that will be added to the next release. Because it does not need API changes, as far as I know today, this feature can be added with a feature flag.