As I have previously mentioned, I’m trying to convert our 5.0.7-based code to 5.1.2.  One of the things I’ve encountered is a fix to a bug that was applied locally, but apparently was never communicated to the net-snmp group, or was never applied, since the bug is present in the 5.1.2 code.  I’ve just opened bug 1038616 against this problem, which also seems related to bugs 860414 and 865415.  The bug description follows.  A patch has been attached to the bug.

 

We have encountered a problem with the way the interfaces mib code (agent/mibgroup/mibII/interfaces.c) calculates and handles ifIndex values in our Linux-based system.  The root cause is that this code uses the ordinal order of appearance in /proc/net/dev as the ifIndex instead of the actual kernel-assigned(?) value that is available via the SIOCGIFINDEX ioctl.  This problem manifests itself when devices are removed from the system.

 

Consider the following generic example.  Three devices are present in /proc/net/dev:

eth0: ....

virt0: ....

wlan0: ....

 

These are assigned SIOCGIFINDEX values as follows:

eth0: 1

virt0: 2

wlan0: 3

 

The values match the ordinal position in /proc/net/dev.  But what happens when virt0 is removed from the system?  We now have:

interface : ordinal value : SIOCGIFINDEX

eth0 : 1 : 1

wlan0 : 2 : 3

 

At this point, if you query the interfaces MIB, you'll discover that all of the wlan0 objects are now using instance 2 instead of instance 3.  This is a violation of the MIB, as well as something that just isn't right.  This is further complicated when you have things like the IP MIB which is using SIOCGIFINDEX to calculate the ifIndex value assigned to a given IP address.

 

In order to fix this, the interfaces MIB code must be modified to use the SIOCGIFINDEX values instead of the ordinal order in /proc/nt/dev when determining the ifIndex of a given interface.  Note that the Win32 code already does something similiar, using pIfTable->table[ifIndex].dwIndex.

 

 

Reply via email to