This is extremely helpful, I think that I have found a bug. Here is what I see
in my logs:
Several rejected traps that are rejected:
snmptrapd:libwrap: UDP: [10.1.1.1]:32770 rejected
Then there will be an occasional trap that gets processed properly, with this
note in the authentication section:
snmptrapd: Running auth trap handlers
snmptrapd:auth: authorization turned off
snmptrapd:auth: authorization turned off: not checking
snmptrapd: Running pre-global trap handlers
snmptrapd:auth: authorization turned off
I see this error message when looking at all of the directives that snmptrapd
understands:
# snmptrapd -H
No log handling enabled - turning on stderr logging
Warning: no access control information configured.
This receiver will *NOT* accept any incoming notifications.
Configuration directives understood:
"disableAuthorization yes" is in my snmptrapd.conf file, but I was using a
custom location. After copying my configuration file to
/etc/snmp/snmptrapd.conf:
# snmptrapd -H
Configuration directives understood:
In the log:
/etc/snmp/snmptrapd.conf: line 57: Warning: Unknown token: disableAuthorization.
Warning: no access control information configured.
This receiver will *NOT* accept any incoming notifications.
In snmptrapd.conf and snmptrapd.local.conf:
Even with this most basic config, snmptrapd and running snmptrapd from the
command line (not as a service), snmptrapd does not understand the directive.
It is also interesting that it is not listed as a token that it understands:
# grep -i auth help
/etc/snmp/snmptrapd.conf: line 1: Warning: Unknown token: disableAuthorization.
ignoreAuthFailure (1|yes|true|0|no|false)
authtrapenable 1 | 2 (1 = enable, 2 = disable)
iquerySecLevel noAuthNoPriv | authNoPriv | authPriv
authcommunity authtype1,authtype2 community
[default|hostname|network/bits [oid|-V view]]
authuser authtype1,authtype2 [-s secmodel] user
[noauth|auth|priv [oid|-V view]]
authgroup authtype1,authtype2 [-s secmodel] group
[noauth|auth|priv [oid|-V view]]
authaccess name authtype1,authtype2 [-s secmodel] group view
[noauth|auth|priv [context|context*]]
rwuser user [noauth|auth|priv [oid]]
rouser user [noauth|auth|priv [oid]]
defAuthPassphrase string
defAuthMasterKey string
defAuthLocalizedKey string
defAuthType MD5|SHA
defSecurityLevel noAuthNoPriv|authNoPriv|authPriv
It looks like all v1 traps work, but v2c do not:
# grep -i "dumph_recv: SNMP" snmptrapd.log
dumph_recv: SNMPv1 message
dumph_recv: SNMPv1 message
dumph_recv: SNMPv1 message
dumph_recv: SNMPv1 message
#
In summary, while using NET-SNMP Version: 5.3.2.2, I see odd behavior with the
disableAuthorization token. It is not listed as a token that snmptrapd
understands, but it does appear to work for v1 traps.
Any ideas?
Jim
On Dec 11, 2010, at 12:11 PM, Wes Hardaker wrote:
>>>>>> On Wed, 8 Dec 2010 09:09:18 -0500, James Donn <[email protected]> said:
>
> JD> Is there a way to trace a single trap OID?
>
> Run snmptrapd with "-d -Ddump,snmptrapd" which should help at least...
> --
> Wes Hardaker
> Cobham Analytic Solutions
Jim
[email protected]
------------------------------------------------------------------------------
Lotusphere 2011
Register now for Lotusphere 2011 and learn how
to connect the dots, take your collaborative environment
to the next level, and enter the era of Social Business.
http://p.sf.net/sfu/lotusphere-d2d
_______________________________________________
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
