>
> http://www.net-snmp.org/wiki/index.php/Net-SNMP_SVN_Usage_Page
>
> on how to properly check out the 5.4.x SVN branch.
Got it, works great, awesome, thanks!
--
- Kyle
-
[EMAIL PROTECTED] http://www.panix.com/~kylet
---
> > traphandler called: Tue Mar 13 15:00:59 2007
> >
>
> This issue has been fixed in SVN (well, CVS at that time). Can you please try
> with the current 5.4.x SVN branch?
>
> See the following (closed) bug report for details:
>
> [ 1638225 ] 5.4 traphandle: unresolved IP translated to
> h
Hi,
I am not getting a host name in output from snmptrapd (5.4)
on Fedora Core 5. I see others mentioning it in the archives and it
being ackknowledged, but no sign of a resolution. DNS is working and
this IP can be resolved to a hostname with dig/host/getent.
traphandler called: Tue Mar
> If you wish to monitor a single instance (nsExtendResult."test1")
> then try adding the flag -I (minus-capital-i). That says to treat
> the test as a single instance, rather than running an snmpwalk
> over it (which will trigger the next instance as well)
That was it - works as desired now. T
> >
> > What about the "agentSecUser" or "iqueryUser" line?
> > Have you configured which user to run internal queries as
> > (and given that user sufficient access) ?
>
> I had not as it wasn't apparent to me from the man page what exactly was
> required for this to work. I have since added a u
>
> > My simple script here, which I can run via snmpget, never gets
> > run my snmpd.
> >
> > extend failure /usr/local/bin/failure
> > monitor -r 1 .
>
> What about the "agentSecUser" or "iqueryUser" line?
> Have you configured which user to run internal queries as
> (and given that user su
Hi,
I am trying to use the "monitor" directive to actively watch some
non-standard items on a Solaris system, but I sense I may be on a wild
goose chase. Should I be able to use "monitor" to essentially run a script
via "extend" in snmpd.conf to check for nsExtendResult != 0 and have a tr
I have not resolved this issue yet - nor heard any
feedback - but in researching it I have discovered
another issue which is causing me similar problems.
It seems snmpd does not fork another daemon when one
its answering to one client like sendmail, imap or
other daemons as I'd expect. I have some
> Net-SNMP 5.2.2 on Solaris 8. Before I go digging further,
> is there any connection between snmpd on a given system and
> the running of snmpget commands on that same system to a
> second remote one, such that the running of the snmpget's
> would disallow connections to snmpd on the first? I
Hi all,
Net-SNMP 5.2.2 on Solaris 8. Before I go digging further,
is there any connection between snmpd on a given system and
the running of snmpget commands on that same system to a
second remote one, such that the running of the snmpget's
would disallow connections to snmpd on the first? I kn
Not sure why I cannot get any response on this. Is it a bug?
> Through a bunch of logging and process of elimination, I was eble
> to force these errors with constant gets of "proc" directives. On
> this particular server, it was checking for sendmail processes.
>
> SNMP OK - 162 | iso.3.6.1.4.1.
Through a bunch of logging and process of elimination, I was eble
to force these errors with constant gets of "proc" directives. On
this particular server, it was checking for sendmail processes.
SNMP OK - 162 | iso.3.6.1.4.1.2021.2.1.5.1=162
Help please ???
> I've dug into this for 2
Hi all,
I've dug into this for 2 days and can't find a thing
on anyone having this issue nor can I duplicate the errors,
even calling every OID in UCD-SNMP-MIB to try and trigger the
errors. Any ideas?
> Hi,
> I'm getting a lot of these errors on newly installed
> systems running s
Hi,
I'm getting a lot of these errors on newly installed
systems running snmpd 5.2.2 on Solaris 10. I saw where in the
code for snmplib/snmp_api.c this is happening, but I can't
make out what would cause it. What should I be looking for?
Thanks.
/proc/14219/psinfo: Bad parse of ASN.1 type
> I had snmpget v3 working fine with between Solaris 8 systems.
> I recently rebuilt the same version of Net-SNMP (5.2.2) on Solaris 10
> and now the same snmpget to the exact same Solaris 8 client gets binary
> garbage back if I request the nsExtendOutputFull OID from any extend
> direc
Hi all,
I had snmpget v3 working fine with between Solaris 8 systems.
I recently rebuilt the same version of Net-SNMP (5.2.2) on Solaris 10
and now the same snmpget to the exact same Solaris 8 client gets binary
garbage back if I request the nsExtendOutputFull OID from any extend
direct
>
> This works well for direct calls from the shell, but Nagios's check_snmp
> plugin is unable in any combination to pass along the quotes to snmpget,
> in fact the program dies trying to do a 'popen' of the command string,
> using its own spopen function. The Nagios mailing list doesn't have a
>
> > If I try to call it with this symbolic name from snmpget, with or
> > without quotes, it fails with:
> >
> > snmpget ... hostname ... nsExtendOutputFull."extt"
>
> You *do* need the quotes, but they need to reach snmpget, rather
> than being swallowed by the shell. Try:
>
> snmpget
>
> No - it *does* fix the repeated execution problem.
> The reasons I suggested you "investigate" it are:
>
> a) The MIB structure is significantly different to the
> original "exec" directive (as you've no doubt discovered).
> Now I believe it's a distinct improvement in flexibil
>
> > Could someone verify that doing the above snmpget command
> > *should* run a given script twice or is it perhaps a bug?
> > I'd expect all fields for for a given exec call to be the
> > result of the same single execution, but I am seeing hard
> > evidence of two runs. Adding any other of
> > On Mon, 2006-02-13 at 13:06 -0500, Kyle Tucker wrote:
> > >Is there a method to obtain both OIDs
> > > (or all for a given exec) with one snmpget call?
> >
> > snmpget ... localhost extResult.1 extOutput.1
>
> This is what I&#
>
> > I may have and so I pulled a clean copy out of the tarball and did
> > a "make clean" and "make" in the agent subdirectory. I got a new snmpd
> > binary but oddly the binary size and checksums are the same, as are the
> > gdb results.
>
> So please apply the patch now and see what happens
> > It would seem that code is already in there.
>
> Nope.
> I've just checked a clean 5.2.2 tarball, and it blindly prints the
> value of the context string, with no checks. I've also checked the
> CVS archive, and there's no mention of this check (or anything similar)
> there either.
>
> I d
> Aha!
> I've just run the same command on my (Linux) 5.2.2 agent,
> and got exactly the same output up to this line.
> But the full text of this last debug line is actually:
>
> register_mib: registering "" at .0 with context "(null)"
>
> So that at least pinpoints where the agent is falling ove
>
>
> On Tue, 2006-02-14 at 16:51 -0500, Kyle Tucker wrote:
>
> > Program received signal SIGSEGV, Segmentation fault.
> > 0xfeeb3218 in strlen () from /usr/lib/libc.so.1
> > (gdb) bt
> > #0 0xfeeb3218 in strlen () from /usr/lib/libc.so.1
> > #1 0xfe
> On Tue, 2006-02-14 at 11:03 -0500, Kyle Tucker wrote:
> > > >
> > > > # snmpd -DALL -f
> > > > Segmentation Fault(coredump)
> > >
> > > It would be rather useful to know *where* it dies.
> > > Can you
I am trying to debug snmpd on Solaris 8 and have run into
some snags. snmpd runs fine in the background, with just a
-p arg. If I try -D, it just dies.
# snmpd -DALL -L /var/log/snmpd.log
trace: main(): snmpd.c, 823:
snmpd/main: optind 3, argc 4
trace: netsnmp_ds_set_string(): default_stor
>
> On Mon, 2006-02-13 at 13:06 -0500, Kyle Tucker wrote:
> >Is there a method to obtain both OIDs
> > (or all for a given exec) with one snmpget call?
>
> snmpget ... localhost extResult.1 extOutput.1
This is what I've been doing and this trigge
Hi folks,
I've built my entire new Nagios system around
obtaining both extResult and extOutput for exec commands
from snmpd.conf. Today I just noticed that this means
I'm running the script in the exec directive twice to
obtain both OIDs. Is there a method to obtain both OIDs
(or all for
29 matches
Mail list logo
