On 09/01/2008, Carlos Rubio <[EMAIL PROTECTED]> wrote:
> pdu = snmp_pdu_create(SNMP_MSG_GET);
> read_objid(".1.3.6.1.2.1.33.1.1.1.0", anOID, &anOID_len);
> snmp_add_null_var(pdu, anOID, anOID_len);
> read_objid(".1.3.6.1.2.1.33.1.1.2.0", anOID, &anOID_len);
> snmp_add_null_var(pdu, anOID, anOID_le
I follow the snmpdemoapp.c and modify the code a litle to get more
than one oid. All works fine so I add more oids but I get errors with
this oid ".1.3.6.1.2.1.33.1.3.3.1.2.1". The error says that oid is not
defined in the mib file, so I try an snmpget command :
snmpget –v 1 –c public 192.168.x.
On 09/01/2008, Michael N Anderson <[EMAIL PROTECTED]> wrote:
> I have seen these OIDs and associated data related to the NET-SNMP MIB
> (where I found your email address):
>
>
> 1.3.6.1.4.1.8072.3.2.10trap=4
> specific=0
> 1.3.6.1.4.1.8072.3.2.10
Hello - One of our Linux server was recently "SNMP enabled" and I (the
event-monitoring administrator) have been unable, so far, to determine
what the traps I am receiving mean (other than "cold start"). I have seen
these OIDs and associated data related to the NET-SNMP MIB (where I found
your
Dave Shield wrote:
> I don't know why the AR check falls back to false rather than :
> So I'll bounce that question back to the person who submitted
> the change :-)
The offending line comes straight from libtool's libtool.m4. It's still the
same line in libtool CVS:
http://cvs.savannah.gnu.org
On 08/01/2008, Thomas Anders <[EMAIL PROTECTED]> wrote:
> Using "false" as the command name almost definitely isn't a sensible way
> to proceed. I haven't even tried to find out yet whether this is a
> problem with autoconf or our configure.in, though. Anyone?
It seems to come from our "aclocal.m4
