On Mon, 2006-01-23 at 21:30 +1000, Nigel Cunningham wrote: > Got it. init_netsnmp_trapd_auth() is within > > #if defined(USING_AGENTX_SUBAGENT_MODULE) > && !defined(SNMPTRAPD_DISABLE_AGENTX)
Hmmm... No - that doesn't feel right. Well spotted - I'll have a look at fixing that. > 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 > Using the -D -f options, I'm seeing the trap being received by the > daemon, but SNMP is still trying to authenticate the user. Yes - it will. That's inherent in a security level of "authNoPriv". Disabling *authorization* just affects the access control settings. It doesn't affect the *authentication* of the request. (Which is probably why Wes was so insistent on the token name!) > 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. No - authentication and authorization are different things, and disableAuthorization shouldn't affect 'authNoPriv' (or 'authPriv') handling. If you don't want user authentication, then use 'noAuthNoPriv'. > Unfortunately, this is not the only issue. Having forwarded the message, the > daemon then segfaults. Urkkk!!! Not good! OK - I'll look into that as well. Dave ------------------------------------------------------- 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