Menu
▾
▴
[ net-snmp-Bugs-1819189 ] ip-mib ipAdEntIfIndex - 0 index values on Solaris 7
|
From: SourceForge.net <no...@so...> - 2007-10-26 11:15:21
|
Bugs item #1819189, was opened at 2007-10-24 03:12 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=112694&aid=1819189&group_id=12694 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: agent Group: solaris Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: ip-mib ipAdEntIfIndex - 0 index values on Solaris 7 Initial Comment: Submitter Email: sma...@ma... Software Version: 5.4.1 Operating System: Solaris 7 (Generic_106541-44) Agent-only compilation compiled for Solaris 7 per... ./configure --prefix=/opt/NetSNMPAgent --enable-as-needed --disable-applications --disable-mibs --disable-mib-loading --disable-des --disable-privacy --disable-md5 --disable-ipv6 --enable-mfd-rewrites --disable-embedded-perl --disable-perl-cc-checks --disable-shared --with-cc=gcc --without-openssl --with-default-snmp-version=2 --with-sys-contact='Not RFC822 Email' --with-sys-location='MyCorp' --with-mib-modules='ucd-snmp/diskio if-mib tcp-mib udp-mib agentx' --with-defaults ... finds itself unable to produce sane ipAdEntIfIndex' ... snmpwalk -On -v2c -c rtyfghvbn73 localhost 1.3.6.1.2.1.4.20.1.2 .1.3.6.1.2.1.4.20.1.2.127.0.0.1 = INTEGER: 0 .1.3.6.1.2.1.4.20.1.2.ip.ad.dr.es = INTEGER: 0 ... vs exactly the same build on Solaris 8 (Generic_117350-18)... .1.3.6.1.2.1.4.20.1.2.127.0.0.1 = INTEGER: 2 .1.3.6.1.2.1.4.20.1.2.ip.ad.dr.es = INTEGER: 2 ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2007-10-26 04:15 Message: Logged In: NO nb: a quick thump on Google turns up this... http://libslack.org/manpages/net.3.html : Solaris (at least 2.6 and 2.7) return -1 as the index for all network interfaces when ioctl(2) is called with a command argument of SIOCGIFINDEX. net_interfaces(3) guesses the indexes when this happens. It starts at 1 for the first interface and increments by 1 for each subsequent interface which seems to work. ... could be a complete red herring, or perhaps an indicator that this issue is a Rumsfeldian known- known? ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2007-10-26 04:03 Message: Logged In: NO Top stuff - and thanks for your time, really, really appreciate it. So for clarity - yes this is a cut/ paste error... > .1.3.6.1.2.1.4.20.1.2.127.0.0.1 = INTEGER: 2 > .1.3.6.1.2.1.4.20.1.2.ip.ad.dr.es = INTEGER: 2 ... it should be ... > .1.3.6.1.2.1.4.20.1.2.127.0.0.1 = INTEGER: 1 > .1.3.6.1.2.1.4.20.1.2.ip.ad.dr.es = INTEGER: 2 ... apologies for the confusion; the ifdef I was referring to is this guy... agent/mibgroup/if-mib/data_access/interface_solaris2.c : netsnmp_arch_interface_index_find(const char *name) { #if defined(HAVE_IF_NAMETOINDEX) return if_nametoindex(name); #else /* use GIFINDEX */ int sd; struct ifreq ifr; : ... and the config.h file is obviously "include/net-snmp/net-snmp-config.h" which is as you'd expect defining HAVE_IF_NAMETOINDEX s 1 on sol8 and undef on sol7. Your little fragment is showing the fault perfectly I think (nb, had to reorder the includes and shift "net/if.h" last, or at least after "sys/socket.h" as the latter defines struct sockaddr implicitly required by the former). For sol8, it fishes up the indicies as expected, but on sol7, we get... # ./getifindex ioctl: No such file or directory ... and truss -f gives us... 18115: munmap(0xFF370000, 8192) = 0 18115: so_socket(2, 1, 0, "", 1) = 3 18115: ioctl(3, 0xC020695A, 0xFFBEF958) Err#2 ENOENT 18115: brk(0x00020B18) = 0 18115: brk(0x00022B18) = 0 ioctl18115: write(2, " i o c t l", 5) = 5 : 18115: write(2, " : ", 2) = 2 No such file or directory18115: write(2, " N o s u c h f i l e".., 25) = 25 18115: write(2, "\n", 1) = 1 18115: close(3) = 0 18115: llseek(0, 0, SEEK_CUR) = 14102 18115: _exit(1) ... (and this regardless of interface name - even for lo0); I take it we have a complete problem definition at this point? nb: in case it matters, sol7 kernel is a ~current 7_Recommended cluster - Generic_106541-44 - and libc likewise. I've not yet hit a point of complete desparation, there's plenty to be getting on with on the sol8 side alone - I can hang fire on the sol7 systems and continue to test/ debug this with your good self (if you have the time free that is, I realise we all have day jobs). Thanks muchly again - big ta. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2007-10-26 04:03 Message: Logged In: NO Top stuff - and thanks for your time, really, really appreciate it. So for clarity - yes this is a cut/ paste error... > .1.3.6.1.2.1.4.20.1.2.127.0.0.1 = INTEGER: 2 > .1.3.6.1.2.1.4.20.1.2.ip.ad.dr.es = INTEGER: 2 ... it should be ... > .1.3.6.1.2.1.4.20.1.2.127.0.0.1 = INTEGER: 1 > .1.3.6.1.2.1.4.20.1.2.ip.ad.dr.es = INTEGER: 2 ... apologies for the confusion; the ifdef I was referring to is this guy... agent/mibgroup/if-mib/data_access/interface_solaris2.c : netsnmp_arch_interface_index_find(const char *name) { #if defined(HAVE_IF_NAMETOINDEX) return if_nametoindex(name); #else /* use GIFINDEX */ int sd; struct ifreq ifr; : ... and the config.h file is obviously "include/net-snmp/net-snmp-config.h" which is as you'd expect defining HAVE_IF_NAMETOINDEX s 1 on sol8 and undef on sol7. Your little fragment is showing the fault perfectly I think (nb, had to reorder the includes and shift "net/if.h" last, or at least after "sys/socket.h" as the latter defines struct sockaddr implicitly required by the former). For sol8, it fishes up the indicies as expected, but on sol7, we get... # ./getifindex ioctl: No such file or directory ... and truss -f gives us... 18115: munmap(0xFF370000, 8192) = 0 18115: so_socket(2, 1, 0, "", 1) = 3 18115: ioctl(3, 0xC020695A, 0xFFBEF958) Err#2 ENOENT 18115: brk(0x00020B18) = 0 18115: brk(0x00022B18) = 0 ioctl18115: write(2, " i o c t l", 5) = 5 : 18115: write(2, " : ", 2) = 2 No such file or directory18115: write(2, " N o s u c h f i l e".., 25) = 25 18115: write(2, "\n", 1) = 1 18115: close(3) = 0 18115: llseek(0, 0, SEEK_CUR) = 14102 18115: _exit(1) ... (and this regardless of interface name - even for lo0); I take it we have a complete problem definition at this point? nb: in case it matters, sol7 kernel is a ~current 7_Recommended cluster - Generic_106541-44 - and libc likewise. I've not yet hit a point of complete desparation, there's plenty to be getting on with on the sol8 side alone - I can hang fire on the sol7 systems and continue to test/ debug this with your good self (if you have the time free that is, I realise we all have day jobs). Thanks muchly again - big ta. ---------------------------------------------------------------------- Comment By: Anders Persson (apersson) Date: 2007-10-25 11:45 Message: Logged In: YES user_id=1557771 Originator: NO If you could compile (cc -o getifindex getifindex.c -lsocket) and run the program below and see what it reports. It will try to grab the index from your loopback interface. Then you change the ifname in the code to be hme0, recompile and run. Once we see what happens we get a patch going. In the meantime, if your main interest is ipAddrTable and you desperately need the ifindex, then compile without --enable-mfd-rewrites, if-mib, tcp-mib and udp-mib. === BEGIN (getifindex.c) === #include <stdio.h> #include <strings.h> #include <unistd.h> #include <net/if.h> #include <sys/ioctl.h> #include <sys/types.h> #include <sys/socket.h> #include <sys/sockio.h> const char ifname[] = "lo0"; int main(void) { struct ifreq ifr; int sd, rv = 0; if ((sd = socket(AF_INET, SOCK_DGRAM, 0)) < 0) { perror("socket"); return (1); } strncpy(ifr.ifr_name, ifname, sizeof (ifname)); if (ioctl(sd, SIOCGIFINDEX, (char *)&ifr) < 0) { perror("ioctl"); rv = 1; } else { printf("if: %s, index: %d\n", ifname, ifr.ifr_index); } close(sd); return (rv); } === END === ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2007-10-25 06:50 Message: Logged In: NO > BTW, looking at the output for Solaris 8, it seems like you have multiple > IPs assigned to the loopback interface. (they have the same index), Is that > the case? Otherwise it seems like we have another problem. Noted - will recheck - suspect cut and paste error :| suspect index was in fact 1 for Sol8, 127.0.0.1 but will make sure tomorrow and update either way. > It appears that the interface index for the loopback device is not set > properly on Solaris 7. Just out of curiosity, could you plumb+up a > non-loopback interface and see if the index is reported properly? System at that point had lo, hme0 plumbed and up - so there's definitely something whacky going on there. > To resolve this problem it looks like we have to revert to the method used > by Interface_Index_By_Name when if_nametoindex() is not available. Yep this is my gut instinct too, I saw the dirty great ifdef in access_data/interface_solaris2.c (going from memory? not in front of system at present), and noted that sol8 has if_nametoindex() while sol7 doesn't (and all this is picked up when the relevant config.h file is built - again sorry for the vagueness, will reupdate again with more precision when I'm back with my build/ test host again tomorrow); unfortunately that was as far as I could take it, to trace debug (I wasn't able to un-knot the calling chain to work out what was calling into that function, and when running with -D ALL I get scads of output _right up to_ the point where I repeat the snmpwalk, where the agent exits and cores). Any clues about what I can do here and now to help isolate? The SIOCGIFNAME stuff in access_data all _eyeballed_ as sane enough (unfortunately I'm only just literate enough to parse what's going on from a 10,000'-above-surface level, not conversant enough with C in general or the agent source to be much real use); I have time to spare to run a test case if you/ anyone can whip up some relevant debug trace points as a quick patch against the source, that much I _can_ do. Of course what I could really use is the proverbial manna-from-above patch that cures my ills and shouts me a bottomless pint while it's at it too, but I'm not quite rude enough to stomp my feet and demand that it appear. :) Unfortunately all of this means that our too-clever management software can't build its IP topology - it wants to model a interface->ip relation (and that, as a precursor to building anything like interface<->interface or interface<->switchport connections, and refuses point blank to build topology or even mark the interface as managed if it can't (ie, it chucks its toys out of the pram over this). Not that this "design" "choice" is Net-SNMP's issue, naturally - but that's where I'm coming at this from if it matters. ---------------------------------------------------------------------- Comment By: Anders Persson (apersson) Date: 2007-10-24 14:34 Message: Logged In: YES user_id=1557771 Originator: NO BTW, looking at the output for Solaris 8, it seems like you have multiple IPs assigned to the loopback interface. (they have the same index), Is that the case? Otherwise it seems like we have another problem. ---------------------------------------------------------------------- Comment By: Anders Persson (apersson) Date: 2007-10-24 14:29 Message: Logged In: YES user_id=1557771 Originator: NO It appears that the interface index for the loopback device is not set properly on Solaris 7. Just out of curiosity, could you plumb+up a non-loopback interface and see if the index is reported properly? To resolve this problem it looks like we have to revert to the method used by Interface_Index_By_Name when if_nametoindex() is not available. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=112694&aid=1819189&group_id=12694 |