Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

enable net-snmp debug

70 views
Skip to first unread message

zhuyj

unread,
Nov 5, 2013, 4:06:26 AM11/5/13
to
1. vi /etc/init.d/snmpd

Modify the OPTIONS to the following:

OPTIONS="-LS0-6d -DALL -Lf /tmp/snmpd.log -p /var/run/snmpd.pid"

2./etc/init.d/snmpd restart

3. tail -f /tmp/snmpd.log

you can see all the debug logs.

tests on net-snmp 5.6

Zhu Yanjun

------------------------------------------------------------------------------
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
_______________________________________________
Net-snmp-coders mailing list
Net-snm...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Bill Fenner

unread,
Nov 29, 2013, 12:52:26 PM11/29/13
to
On Mon, Oct 28, 2013 at 7:01 AM, Fulko Hew <fulk...@gmail.com> wrote:
I was bit recently by a design limitation on the length of OCTET STRINGS
as received and processed by AgentX.

...
Comments?

I think the dual to this problem has also been reported at https://sourceforge.net/p/net-snmp/bugs/2489/ - a SET request with a big octet string fails to pass from master to subagent, just like the trap with a big octet string fails to pass from subagent to master.

My thoughts:

1. Both of these expose a secondary issue (e.g., Fulko experiences that the master agent appears to hang, Stian experiences that the subagent fails in some way).  These secondary issues deserve to be addressed.

2. The agentx transport should be able to handle these large strings, especially since agentx runs over a stream protocol and has no control over underlying packet sizes anyway.

  Bill

0 new messages