On Wed, Dec 19, 2018 at 12:39:07AM +0000, Roedersheimer, Drew A. wrote: > Denis Hainsworth wrote: > > #2899 - snmptrap bug > > #2900 - snmptrapd bug > > > > -denis > > Denis, > > Sorry for the delayed response. I haven't had time to look at this until > recently. > > Regarding the snmptrapd bug you created (#2900): I think this is working as > expected. > I compiled and tested v5.7.3 from git source, and snmptrapd is certainly > validating the > msgAuthoritativeEngineBoots value. Whenever I send a trap with a boot value > that is > the same or greater than the last, the trap is received. If I send a trap > with a > boot value that is less than a previous trap, I get the following error from > snmptrapd: > > usm: USM processing begun... > usm: match on user testuser > usm: Verification succeeded. > usm: Remote boot count invalid. > > > As for the msgAuthoritativeEngineTime values, if the delta from the previous > trap > is large enough, the trap is also rejected by snmptrapd. Here's the message > you > will see (with -Dusm): > > usm: USM processing begun... > usm: match on user testuser > usm: Verification succeeded. > usm: Message too old. > > I haven't dug into the code deep enough to find the threshold, but I suspect > it's > following the RFC. > > The end result is that I think that bug #2900 should be closed as invalid. > > Please let me know your thoughts.
Dug into this some more. I see whats happening and not sure if its a bug per se but I do agree that if there is a non-buggy trap sender its all working properly so will close the bug with some comments. So per rfc2574 the only requirement is that a trap boots/time be at most 150s behind the last message received. Plus that boots/time always starts at 0/0. So because snmptrap binary we were using was always setting boots/time to 0/0 that was never less than 150s older so snmptrapd happily accepts the messages which I though meant it wasnt checking. This is namely because Cisco Prime Network snmp trap receiver throws the "notintimewindow" error for 0/0. I believe this is a restriction technically outside the strict reading of the RFC. I couldn't find a section that mandated the snmp receiver should error if boot/time never changes and/or always stays at 0/0. In this sense i think snmptrapd is potentially more RFC compliant but less restrictive than cisco. As you noted if I use a functional snmptrap program where I am able to set the boots/time and advance it to non zero values than I can see that I get proper errors if I back the time up past 150s prior to the latest time sent. So i'll update and close the snmptrapd bug. nice catch sorry for the confusion. -denis _______________________________________________ Net-snmp-coders mailing list Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
