HI
The below looks like a good thing.
It doesn't add the capability that I would like to see, which
was specified in previous email. That is, a way to turn on
categorization of TRAPs and INFORMs sent to the notification
receiver. This would really help. The problem that I ran into
yesterday was that I had changed the engineID of my agent,
but I had not caused it to be applied. All of the TRAPs
were being sent with msgAuthoritativeEngineID that was the
old one. There were no users in the snmptrapd.conf for the
old engineID. I found this problem by sniffing the packets.
It would have been much better if the message categorization
was output. For example I might have seen:
msg=1, proto=v3, msgId=34, mm=2048, sl=noAuthNoPriv, sm=usm,
aID=00000063000000A2C0A8A863, b=45, t=23456, u=testuser,
s=noSuchUser
msg=2, proto=v3, msgId=89, mm=2048, sl=authNoPriv, sm=usm,
eId=00000063000000A2C0A8A822, b=2, t=287, u=testuser,
s=OK, cID=00000063000000A2C0A8A822, cnt="", op=TRAP
The above shows the first message is v3/USM with user "testuser",
and fails because no such user exists with the authoritative
engineID. The second message succeeds the authentication
test, and is further decoded to see that it is TRAP message.
Now, the decode could go further and continue where the
current decode starts!
Wes - on the current snmptrap, what happens if you send it
an SNMP message type other than TRAP or INFORM, such as GET,
RESPONSE, etc? In the proposed output above, if the
authenication (and possibly the decryption) was OK, the
message would fail when the operation type was processed.
So, maybe the output should be modified so the "s="
is replaced by "f=" (fail), and the decoding of the
message end with a "f=" or it succeeds. If it was
done this way, the fail reason could even support
many ASN.1 parse failures. On the config, it would be
nice to say which of the above fields should be printed
out.
On Fri, 2 Sep 2005, Wes Hardaker wrote:
> >>>>> On Fri, 02 Sep 2005 16:25:04 -0700, Wes Hardaker <[EMAIL PROTECTED]>
> >>>>> said:
>
> Wes> /me wonders how much of the VACM code could be leveraged to apply
> Wes> here... Much of the requirements are actually similar.
>
> /me puts his fingers where his mouth is.
>
> I'd like to propose something like the following.
<rest cut>
/david t. perkins
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
