The exact code that is giving me problems is the ioctl call using SIOCGIFINDEX
in the netsnmp_access_interface_ioctl_ifindex_get() function. From what I've
been told the increasing index number for PPP interfaces is the kernel's
designed behavior. Our kernel dev pointed out that in our kernel's
drivers/net/ppp/ppp_generic.c code the function ppp_register_net_channel() does
this:
Pch->file.index = ++pn->last_channel_index;
So each time this is invoked it will increase the index number.
I can't seem to call Interface_Index_By_Name() anymore because of several
compile issues. The 'configure' file (version 5.5.1) says that the module
"mibII/interfaces" is an "old ifTable implementation". I assume that means it
is not used anymore.
What I ended up doing was removing the ioctl call from
netsnmp_access_interface_ioctl_ifindex_get() and replacing it with a function I
wrote that assigns an index number to an interface based on its position in the
/proc/net/dev file. From what I can tell that is what
Interface_Index_By_Name() was doing. With this change in place all of the
strange behavior I was seeing (two ppp0 interfaces reported by snmpd,
increasing interface index numbers) went away. Comparing results from before
my fix and after my fix showed that the interfaces are assigned the same
numbers.
I don't need help anymore. I just thought that this would be useful
information to anyone that encounters this problem.
---- On Wed, 20 Jun 2012 15:59:48 -0700 christopher.wu wrote ----
>I can add some more insight to my original question.
>
>After the first time I bounce the PPPoE daemon snmpd (version 5.5.1) returns
>two ppp0 interfaces. After a few minutes the first one will disappear. Before
>that could happen I decided to restart snmpd to see what it would return.
>
>
>IF-MIB::ifIndex.15 = INTEGER: 15
>IF-MIB::ifIndex.16 = INTEGER: 16
>IF-MIB::ifIndex.17 = INTEGER: 17
>IF-MIB::ifIndex.18 = INTEGER: 18
>
>IF-MIB::ifDescr.15 = STRING: eth0.2222
>IF-MIB::ifDescr.16 = STRING: eth0.3030
>IF-MIB::ifDescr.17 = STRING: ppp0
>IF-MIB::ifDescr.18 = STRING: ppp0
>
>Restart snmpd at this point.
>
>IF-MIB::ifIndex.15 = INTEGER: 15
>IF-MIB::ifIndex.16 = INTEGER: 16
>IF-MIB::ifIndex.18 = INTEGER: 18
>
>IF-MIB::ifDescr.15 = STRING: eth0.2222
>IF-MIB::ifDescr.16 = STRING: eth0.3030
>IF-MIB::ifDescr.18 = STRING: ppp0
>
>ppp0's index is 18 at this point and there is no longer an index 17.
>
>Can you provide any insight as to why this is happening, or better yet how to
>stop it?
>
>Thank you.
>
>---- On Tue, 05 Jun 2012 12:02:48 -0700 christopher.wu wrote ----
>
>
> >
> > First off, apologies for what will be a lengthy post, but I wanted to
> > include as much background as possible to help with a potential answer.
> > When we were running net-snmp version 5.2.5.1 (on an embedded Linux system)
> > we encountered a customer that complained that their SNMP poller was
> > complaining of “unknown” interfaces from the SNMP results we were
> > returning. After some research I realized that there were problems with the
> > interfaces being returned when PPPoE connections are used. PPPoE
> > connections seem to get assigned a new IP address relatively frequently
> > (compared to DHCP). I can easily recreate this by just killing the running
> > pppd daemon. When I do that the new IP address assigned to the ppp0
> > interface is returned by ipAdEntIfIndex with an index number that has
> > increased by one. However, the values returned by ifNumber, ifDescr,
> > ifIndex, etc all remain the same. Therefore ipAdEntIfIndex is using an
> > index number that references an interface that does not exist.
> > I studied the SNMP code and fixed it by modifying the
> > netsnmp_access_interface_ioctl_ifindex_get() function. Instead of just
> > returning ifrq.ifr_ifindex, I compare that value to what the
> > Interface_Index_By_Name() function would return for that interface. If they
> > don't match then I force the correct value to be returned. I added the code
> > in “NEW_CODE”.
> >
> >
> > DEBUGMSGTL(("access:interface:ioctl", "ifindex_get"));
> >
> >
> > rc = _ioctl_get(fd, SIOCGIFINDEX, &ifrq, name);
> >
> >
> > if (rc < 0) {
> >
> >
> > DEBUGMSGTL(("access:interface:ioctl",
> >
> >
> > "ifindex_get error on inerface '%s'", name));
> >
> >
> > return 0;
> >
> >
> > }
> >
> >
> >
> >
> >
> >
> > #ifdef NEW_CODE
> >
> >
> > returnValue = ifrq.ifr_ifindex;
> >
> >
> > if (NULL != strstr(name, "ppp"))
> >
> >
> > {
> >
> >
> > foundIndex = Interface_Index_By_Name(name, sizeof(name));
> >
> >
> >
> >
> >
> >
> > if (foundIndex != returnValue && foundIndex > 0)
> >
> >
> > {
> >
> >
> > snmp_log(LOG_DEBUG, "%s %d would have returned [%s] iface index %d but will
> > use %d.",
> >
> >
> > __func__, __LINE__, name, returnValue, foundIndex);
> >
> >
> > returnValue = foundIndex;
> >
> >
> > }
> >
> >
> > }
> >
> >
> > #endif
> >
> >
> >
> >
> > That worked great and then customer was happy. Later we updated to net-snmp
> > version 5.5.1. I noticed that this area of code was completely different
> > and that snmpd was acting differently in this scenario. When I bounce the
> > pppd daemon snmpd will temporarily report two different ppp0 interfaces,
> > even though the /proc/net/dev file shows only one instance of ppp0. The
> > newer instance has an index value of one more than the old instance.
> >
> >
> > IF-MIB::ifDescr.15 = STRING: eth0.2222
> > IF-MIB::ifDescr.16 = STRING: eth0.3030
> > IF-MIB::ifDescr.19 = STRING: ppp0
> > IF-MIB::ifDescr.20 = STRING: ppp0
> >
> >
> > IF-MIB::ifNumber.0 = INTEGER: 18
> >
> >
> >
> >
> > # cat dev
> >
> >
> > Inter-| Receive | Transmit
> >
> >
> > face |bytes packets errs drop fifo frame compressed multicast|bytes packets
> > errs drop fifo colls carrier compressed
> >
> >
> > lo: 42034 429 0 0 0 0 0 0 42034 429 0 0 0 0 0 0
> >
> >
> > teql0: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> >
> >
> > tunl0: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> >
> >
> > gre0: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> >
> >
> > eth0: 928024 5397 0 0 0 0 0 0 2323119 5846 0 0 0 0 0 0
> >
> >
> > eth1: 1630819 2335 0 9 0 0 0 0 350976 2319 0 0 0 0 0 0
> >
> >
> > ipsec0: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> >
> >
> > ipsec1: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> >
> >
> > ipsec2: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> >
> >
> > ipsec3: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> >
> >
> > mast0: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> >
> >
> > eth0.4069: 852516 5398 0 0 0 0 0 0 2318569 5803 0 0 0 0 0 0
> >
> >
> > eth0.666: 0 0 0 0 0 0 0 0 1572 14 0 0 0 0 0 0
> >
> >
> > eth0.888: 0 0 0 0 0 0 0 0 498 5 0 0 0 0 0 0
> >
> >
> > eth0.2222: 0 0 0 0 0 0 0 0 1532 14 0 0 0 0 0 0
> >
> >
> > eth0.3030: 0 0 0 0 0 0 0 0 498 5 0 0 0 0 0 0
> >
> >
> > ppp0: 5636 31 0 0 0 0 0 0 7856 36 0 0 0 0 0 0
> >
> >
> >
> >
> > After a few minutes the 'old' ppp0 will disappear in the SNMP results
> > returned. As this process repeats the index value for ppp0 keeps getting
> > higher and higher. However, ipAdEntIfIndex and all of the interface stats
> > (ifNumber, ifDescr, ifIndex, etc) all consistently refer to the current new
> > value.
> >
> >
> > IF-MIB::ifDescr.15 = STRING: eth0.2222
> > IF-MIB::ifDescr.16 = STRING: eth0.3030
> > IF-MIB::ifDescr.20 = STRING: ppp0
> >
> >
> > IF-MIB::ifNumber.0 = INTEGER: 17
> >
> >
> > I decided to keep this code the way it was since testing with the customer
> > showed that their tool was fine with this behavior.
> > Unfortunately now I have a completely different customer with a similar
> > complaint. Their netflow tool (which creates reports based on SNMP polling
> > results) is complaining about “unmanaged” interfaces. I strongly suspect
> > this is being caused by ppp0's continuously increasing index numbers. Can
> > you provide any insight as to why this is happening, or better yet how to
> > stop it? I did recently find an old bug report ([ net-snmp-Bugs-1238857 ]
> > ipAdEntIfIndex out of sync with ifIndex) that suggests compiling with
> > “--enable-mfd-rewrites”, but that didn't change anything for me.
> > Thank you
> >
>
>
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Net-snmp-users mailing list
Net-snmp-users@lists.sourceforge.net
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users
