Hi.
Sorry for the slow reply. I sent this on Friday, but used the wrong identity,
so the list server didn't let it through...
On Thursday 19 January 2006 20:05, Dave Shield wrote:
> On Thu, 2006-01-19 at 15:10 +1000, Nigel Cunningham wrote:
> > > disableAuthorization yes
> > > will disable the above access control checks,
> > > and revert to the previous behaviour of
> > > accepting all incoming notifications.
> >
> > I tried this, and get:
> >
> > trace: read_config(): read_config.c, 780:
> > read_config: /etc/snmp/snmptrapd.conf:15 examining: disableAuthorization
> > yes /etc/snmp/snmptrapd.conf: line 15: Warning: Unknown token:
> > disableAuthorization.
>
> Hmmm....
> I know this is probably an obvious question, but which version of
> snmptrapd are you running with? Your patched 5.2.2 or 5.3/5.3.0.1 ?
>
> The disableAuthorization token was introduced with 5.3, and wouldn't
> be recognised by earlier releases. (Since they didn't do authorization
> checks at all!)
>
>
> I get the following:
>
> # cd net-snmp-5.3
> # ./apps/snmptrapd -f -Le
> Warning: no access control information configured.
> This receiver will *NOT* accept any incoming notifications.
> NET-SNMP version 5.3
> [^C]
> 2006-01-19 09:58:26 NET-SNMP version 5.3 Stopped.
> Stopping snmptrapd
> # vi /usr/local/etc/snmp/snmptrapd.conf
> [add "disableAuthorization yes"]
>
> # sudo ./apps/snmptrapd -f -Le
> NET-SNMP version 5.3
> [^C]
> 2006-01-19 09:58:30 NET-SNMP version 5.3 Stopped.
Got it. init_netsnmp_trapd_auth() is within
#if defined(USING_AGENTX_SUBAGENT_MODULE)
&& !defined(SNMPTRAPD_DISABLE_AGENTX)
so it's having a non-standard config that's tripping me up.
I should give you the original configure options (that worked fine with 5.2.1
but now don't). You might say they're broken to begin with. If you do, I'll
say "That's ok." because I just inherited them :)...
./configure --with-transports="UDP TCP" \
--with-out-transports="UDPIPv6 TCPIPv6 IPX ALL5PVC" \
--with-persistent-directory="/var/net-snmp" \
--datadir=/usr/share \
--sysconfdir=/etc \
--with-default-snmp-version="2" \
--with-entreprise-oid=2925 \
--with-sys-contact="[EMAIL PROTECTED]" \
--with-sys-location="Cyclades OnBoard" \
--with-logfile="/var/log/snmpd.log" \
--enable-shared \
--enable-static \
--with-mib-modules="mibII snmpv3mibs ucd_snmp cyacsmgmt " \
--with-out-mib-modules="host agentx utilities notification
agent_mibs tunnel target disman "
Now on to other problems...
I'm trying from another machine:
snmptrap -e 0x0102030405 -v 3 -u myuser -a MD5 -A mypassword -l authNoPriv
192.168.128.106 42 coldStart.0
(This comes straight from the tutorial on the website, with only the IP
address changed). 106 is of course the box running netsnmptrapd, with the
config:# snmptrapd.conf
#
# Please read the man page for snmptrapd.conf on a computer with snmp
installed
# for details on how to configure this file. The only Cyclades specific
extension
# to the snmptrapd.conf format is that we allow you to filter trap forwarding
# according to the source of the trap:
#
# forward [-s source_address] OID|default DESTINATION
#
# Source address can be:
# - hostname (resolved at startup)
# - ip address
# - netmask (192.168.0.0/255.255.0.0)
disableAuthorization yes
forward -s 192.168.128.112 .1.3.6 192.168.128.112
Using the -D -f options, I'm seeing the trap being received by the daemon, but
SNMP is still trying to authenticate the user. I ran the trap daemon with ddd
(by compiling everything with -g and editing the snmptrapd to run ddd). With
this config, I set breakpoints on each of the three functions in
snmptrapd_auth.c, and only see the init_ function invoked at start up.
Sending the above trap does not invoke netsnmp_trapd_auth. Instead as was the
case with 5.2.1, we enter usm_process_in_msg, and it rejects the username.
The call trace is:
snmp_api.c 3812: (*sptr->decode) ()
snmp_api.c: 4170: snmpv3_parse();
snmp_api.c:4234: _snmp_parse()
snmp_api.c:5147 snmp_parse()
snmp_api.c:5747: _sess_process_packet();
snmp_api.c: 5766: _sess_read();
snmp_api.c: 5386: snmp_sess_read()
snmp_trapd.c: 1255: snmp_read();
Testing further, this time with the user existing in the trapd daemon's conf
file, I make it past this point, and do indeed see the disableAuthorization
parameter take effect on later checking, so it just seems to need to be also
applied at this earlier point.
Unfortunately, this is not the only issue. Having forwarded the message, the
daemon then segfaults. The problem appears to arise from the fact that when
snmpv3_packet_realloc_rbuild is invoked, it does a straight copy of the
pdu->securityStateRef address rather than copying the contents and passing
the duplicate's address in the params struct. When usm_regenerate_out_msg is
finished with params, it invokes usm_free_usmStateReference(secStateRef)
directly. _sess_process_packet later calls (*sptr->pdu_free_state_ref) with
the same address, resulting in a double free. With my simplistic
understanding of what is going on, I first tried setting the pdu variable to
NULL after copying the value, to no avail. When I instead inhibited
usm_regenerate_out_msg from doing the first free, I was able to see a trap
getting forwarded without snmptrapd then segfaulting. I'm not sure that this
is the perfect solution, though, as I didn't follow all the code paths to
check that this is the right action for every circumstance.
Hope this helps!
Regards,
Nigel
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Net-snmp-users mailing list
Net-snmp-users@lists.sourceforge.net
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users
