On 1 March 2011 12:41, Andy Brown <[email protected]> wrote: > thanks for the fast reply. I'd not be surprised if the device sending the > traps sends them malformed or buggy, so we could be onto something. I've > logged with both debugs and the traps are definitely in there:
OK - I think I might have found the problem. I had a quick look at the first dump, and at first glance the trap looks fine. But on closer examination (and comparing it with an equivalent manually generated trap), there are a couple of issues with the length length encodings. The packet as a whole starts "30 81 5E", which means "this is a sequence, containing 222 octets". Then a bit later in the request (at the end of the first line of the dump) comes "A4 4B" which means "This is an SNMPv1 trap, containing 75 octets" Unfortunately, if you actually count the number of octets that follow the "A4 xx" point, there are actually 81 more octets (which would be encoded "A4 4B". So when the library starts parsing the last element of this request (the VarbindList, starting "30 34 30 32") it discovers that the data to be parsed is incomplete. The overall length is also wrong - it should begin "30 5F", indicating 95 octets of content I don't understand why sending the trap to the other snmptrapd process works, but that looks to be where the problem lies. Dave ------------------------------------------------------------------------------ Free Software Download: Index, Search & Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev _______________________________________________ Net-snmp-users mailing list [email protected] Please see the following page to unsubscribe or change other options: https://lists.sourceforge.net/lists/listinfo/net-snmp-users
