v5.2.2 snmpget, set complain about index type for ifIndex

Logged In: YES
user_id=107514

I've simplified my table handler a lot to just access a
static array:

static long power[MAX_IF];

long*
get_testAdminPower(void *data_context, size_t *ret_len)
{
long port;

   port = ctx2port\(data\_context\);
   snmp\_log\(LOG\_DEBUG, "<<GET power for %ld, value is

%ld\n", port, power[port]);
*ret_len = sizeof(long);
return &power[port];
}

int
set_testAdminPower(void *data_context, long *val, size_t
val_len)
{
long port;

   port = ctx2port\(data\_context\);
   snmp\_log\(LOG\_DEBUG, ">>SET power for %ld, new value

is %ld\n", port, *val);
power[port] = *val;
return SNMP_ERR_NOERROR;
}

and I see this:

# snmpget -v 2c -c private ipm SIXNET-MIB::ifAdminPower.1
Unexpected index type: 0 ifIndex 1
SIXNET-MIB::ifAdminPower.1 = INTEGER: unknown(0)
# snmpset -v 2c -c private ipm SIXNET-MIB::ifAdminPower.1 i 2
Unexpected index type: 0 ifIndex 1
SIXNET-MIB::ifAdminPower.1 = INTEGER: down(2)
# snmpget -v 2c -c private ipm SIXNET-MIB::ifAdminPower.1
Unexpected index type: 0 ifIndex 1
SIXNET-MIB::ifAdminPower.1 = INTEGER: unknown(0)

and my log contains:

<<GET power for 1, value is 0
<<GET power for 1, value is 0
<<GET power for 1, value is 0
<<GET power for 1, value is 0

*NO* calls of the set routine!

Logged In: YES
user_id=107514

Failure to set was my bad. I added a column and didn't get
my table handler right. That's working now. The erroneous
Unexpected index type message is still a pain.

Logged In: YES
user_id=848638

Sorry, I don't get this message with stock CVS MAIN or
V5-2-patches on Linux/x86. Looks like being special to your
setup.

Logged In: YES
user_id=107514

How did you test? It seems to only happen with certain
tables. Specifically, I know it happens with ifIndex (as in
RFC1213-MIB::ifIndex.1).

FWIW, my configure options are:

./configure --prefix=/usr \ --target=powerpc-linux \ --host=powerpc-linux \ --build=i386-pc-linux \ --with-openssl=/usr/local/ssl/bin \ --with-endianness=big \ --with-cc=powerpc-linux-gcc \ --with-ar=powerpc-linux-ar \ --with-install-prefix=/IPm \ --with-cflags="-O2" \ --enable-applications \ --disable-mib-loading \ --disable-scripts \ --with-sys-location="Blah" \ --with-sys-contact="Blah" \ --with-logfile="/var/log/snmpd.log" \ --with-default-snmp-version="3" \ --with-persistent-directory="/var/net-snmp"

Logged In: YES
user_id=848638

I tested exactly like you proposed: snmpget -v2c -c foobar
localhost RFC1213-MIB::ifIndex.1. Again, this works fine for
a stock 5.2.2 or 5.3.pre5 build.

Can you retest this on a local machine with a default build
(plain ./configure)?

Logged In: YES
user_id=107514

I rebuilt with:

# ./configure --prefix=/usr
# make
# make install

and then I still get:

# snmpget -v 2c -c public ipm RFC1213-MIB::ifIndex.1
Unexpected index type: 0 ifIndex 1
RFC1213-MIB::ifIndex.1 = INTEGER: 1

FWIW:

# uname -a
Linux eng8 2.4.18-3smp #1 SMP Thu Apr 18 06:59:55 EDT 2002
i686 unknown
# gcc -v
Reading specs from
/usr/lib/gcc-lib/i386-redhat-linux/2.96/specs
gcc version 2.96 20000731 (Red Hat Linux 7.3 2.96-110)

Logged In: YES
user_id=848638

Is this with 5.2.2? Please run snmpget with
"-Dparse-mibs,read_config" to see what config files and MIBs
it reads. Post the content of the configuration files and
verify whether RFC1213-MIB is the version shipped with 5.2.2.

Logged In: YES
user_id=107514

Is this with 5.2.2?

Yes.

Please run snmpget with "-Dparse-mibs,read_config" to see
what config files and MIBs it reads.

~1k lines of log attached.

Post the content of the configuration files

None that seem to be reported in the attached log.
Shouldn't it process /usr/share/snmp/snmpd.conf by default?

and verify whether RFC1213-MIB is the version shipped with
5.2.2.

Would the MIB have changed?

It has a timestamp consistent with when I last installed
v5.2.2. In /usr/share/snmp/mibs and where I untarred and
built v5.2.2 I see:

# md5sum /usr/share/snmp/mibs/RFC1213-MIB.txt
f05e4af8c75fb4c416412ef7fcc919e2
/usr/share/snmp/mibs/RFC1213-MIB.txt
# md5sum /home/chrisn/snmp/net-snmp-5.2.2/mibs/RFC1213-MIB.txt
f05e4af8c75fb4c416412ef7fcc919e2
/home/chrisn/snmp/net-snmp-5.2.2/mibs/RFC1213-MIB.txt

Output of snmpget -Dparse-mibs,read_config

Logged In: YES
user_id=76148

As this is only happening in your custom table and not our ifTable, I have to assume it's something in your code.

I suggest that this discussion be continued on the coders list.

Logged In: YES
user_id=107514

We can discuss it anywhere you want but it's not just in my
table. It shows up in RFC1213-MIB, too.

# snmpget -v 2c -c public ipm RFC1213-MIB::ifIndex.1
Unexpected index type: 0 ifIndex 1
RFC1213-MIB::ifIndex.1 = INTEGER: 1

Logged In: YES
user_id=107514

Did Net-SNMP's MIB parsing get fussier between v5.1.1 and
v5.2.2? I found this with smilint just now:

# smilint /usr/share/snmp/mibs/RFC1213-MIB.txt 2>&1 | more
/usr/share/snmp/mibs/RFC1213-MIB.txt:258: index element
`ifIndex' of row `ifEntry' must have a range restriction
/usr/share/snmp/mibs/RFC1213-MIB.txt:606: index element
`atIfIndex' of row `atEntry' must have a range restriction
/usr/share/snmp/mibs/RFC1213-MIB.txt:1298: index element
`ipNetToMediaIfIndex' of row `ipNetToMediaEntry' must have a
range restriction

These are the same entities that are causing the Unexpected
index type messages. Maybe it's just a coincidence.

Logged In: YES
user_id=88893

I've been trying to reproduce this problem (using a
clean installation of 5.2.2) - but without success.

Can you please confirm the *exact* configuration
that you're working with?

No - our MIB parsing shouldn't changed significantly.
smilint is a lot fussier, and will complain about
various things that our MIB parser is quite happy with.
The two are very different tools, and intended for
different purposes. We take a fairly pragmatic
approach to MIB files, while the whole raison d'etre
of smilint is to be picky!

Logged In: YES
user_id=1312539
Originator: NO

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 180 days (the time period specified by
the administrator of this Tracker).