OK,
What I do now is a
snmpwalk -v 2c -c public 10.115.221.35 .1.3.6.1.4.1.3032.64.4
or to be compatible with 5.1.1
snmpdata=`snmpwalk -v 2c -c $1 $2 .1.3.6.1.4.1.3032.65 | grep "STRING" | awk
-F"\"" '{ print "\n"$2 }'| tail -n1`
echo $snmpdata
cheers
>>> "Dave Shield" <[EMAIL PROTECTED]> schr
On 20/07/07, Dave Shield <[EMAIL PROTECTED]> wrote:
> First table - configuration (enterprises.3032.65.2.1... - see
> nsExtendConfigEntry)
[snip]
> Second table - configuration (enterprises.3032.65.3.1... - see
> nsExtendOutput1Entry)
Second table - basic output
[snip]
> Second tab
On 20/07/07, Thomas Zenz <[EMAIL PROTECTED]> wrote:
Scalar objects:
> SNMPv2-SMI::enterprises.3032.65.1.0 = INTEGER: 1
1 entry registered under enterprises.3032.65 (nsExtendNumEntries)
First table - configuration (enterprises.3032.65.2.1... - see
nsExtendConfigEntry)
> enterprises.3032.
On 20/07/07, Thomas Zenz <[EMAIL PROTECTED]> wrote:
> OK, but what about my Question concerning the MIB Structure,
The MIB structure is basically that defined in the MIB file
NET-SNMP-EXTEND-MIB
with the OID that you specify as the root (instead of 'neExtendObjects').
It now has three separa
OK, but what about my Question concerning the MIB Structure, that's now twice
as log and allways different for different OIDs and somtimes even different on
different machines.
(See below)
My old config was a snmpget on .1.3.6.1.4.1.3032.65.101.1 and received the
string.
Now for my exec 3032.65
On 19/07/07, Kelsey Cummings <[EMAIL PROTECTED]> wrote:
> Perhaps for clarity's sake ucd-snmp/extensible.c could be updated so the
> error implies that the feature is depcrated but support for it is enabled.
I've been slightly naughty, and updated the warning message ahead of
the next (last?) 5.4.
On Thu, Jul 19, 2007 at 09:41:02PM +0100, Dave Shield wrote:
> On 19/07/07, Kelsey Cummings <[EMAIL PROTECTED]> wrote:
> >> Sorry - try
> >>
> >>--with-mib-modules=ucd-snmp/extensible
> >
> >That seems to have done the trick, though the error it still spits out is a
> >bit misleading since it's
On 19/07/07, Kelsey Cummings <[EMAIL PROTECTED]> wrote:
> > Sorry - try
> >
> >--with-mib-modules=ucd-snmp/extensible
>
> That seems to have done the trick, though the error it still spits out is a
> bit misleading since it's the same as the error raised by agent/extend.
> Perhaps for clarity's
On Thu, Jul 19, 2007 at 09:20:57PM +0100, Dave Shield wrote:
> On 19/07/07, Kelsey Cummings <[EMAIL PROTECTED]> wrote:
> >> ./configure --with-mib-modules=ucd-snmp/exec
> >
> >That module doesn't exist in the 5.4.1.rc3 source tree, did you mean
> >something else?
>
> Sorry - try
>
>--with-m
On 19/07/07, Kelsey Cummings <[EMAIL PROTECTED]> wrote:
> > ./configure --with-mib-modules=ucd-snmp/exec
>
> That module doesn't exist in the 5.4.1.rc3 source tree, did you mean
> something else?
Sorry - try
--with-mib-modules=ucd-snmp/extensible
> > > what is the reasoning behind re
On Thu, Jul 19, 2007 at 08:29:56PM +0100, Dave Shield wrote:
> On 19/07/07, Kelsey Cummings <[EMAIL PROTECTED]> wrote:
> >Is there any way to enable exec support in 5.4.1?
>
> ./configure --with-mib-modules=ucd-snmp/exec
That module doesn't exist in the 5.4.1.rc3 source tree, did you mean
somet
On 19/07/07, Kelsey Cummings <[EMAIL PROTECTED]> wrote:
> Is there any way to enable exec support in 5.4.1?
./configure --with-mib-modules=ucd-snmp/exec
> what is the reasoning behind removing backwards compatibility?
The output is invalid.
It doesn't form a legal MIB structure.
Dave
On Thu, Jul 19, 2007 at 05:31:33PM +0200, Thomas Zenz wrote:
> Hi,
>
> I updated my Server from 5.1.1 to 5.4 my snmp.conf dose not work
> anymore.
I just upgraded a host to 5.4.1.rc3 to test if it is affected by bug
1729562 and ran into the same problem. We have quite a bit of software
that rel
13 matches
Mail list logo
