Hi Robert, On Monday, January 26, 2015 9:22 AM, David Hauck wrote: > Hi Robert, > > On Sunday, January 25, 2015 9:03 PM, NetSNMP Mailbox wrote: >> On Wed, 7 Jan 2015 00:40:57 +0000 David wrote: DH> I ran into an >> insidious agent (snmpd) hang on Linux that had me DH> stumped for >> quite a while. The hang occurred when attempting to DH> walk DH> >> mib-2 and always occurred during attempts to walk DH> TCP-MIB::tcpConnTable. >> At first I thought this might be related to DH> my build of v5.7.3 'snmpd' >> (see below), but I eventually DH> discovered that this was related >> to the fact that the system the DH> agent was running on did not >> have netlink socket diagnostics DH> configured in the kernel. When >> this is the case the netlink DH> (TCPDIAG_GETSOCK) response returns >> an error; the v5.7.3 version of DH> agent/mibgroup/mibII/tcpTable.c >> does not handle this case and the DH> specific code ends up in an infinite >> wait. >> DH> DH> I've enclosed a patch that illustrates one way of fixing this. >> DH> This simply logs an error and then returns from the loop when >> DH> this case is encountered. The additional check for a non-zero >> DH> error DH> >> code isn't exactly needed in this case since the original netlink >> DH> message isn't requesting an ACK (netlink ACKs are returned as >> DH> NLMSG_ERROR message DH> types, but with a zero error code). >> However, I've left in this DH> check for completeness. I've also >> removed a redundant assignment to the 'r' pointer. >> >> David, >> >> Thank you for investigating this issue and sending us a patch. I've >> applied to to all active branches which have this code. > > Excellent, thx. > >> DH> * I mentioned that I thought this was originally an issue >> DH> related to the build. I still think there are issues with the new >> 'libnl3' >> DH> support that was added in v5.7.3. I'm not an 'autoconf' expert >> DH> so I won't go into details about it, but I can describe at a >> DH> high level what I think is wrong. >> >> Can you please file a bug with this info for the autoconf issue? > > Will do.
After going over this again (remember please that I'm not an 'autoconf' expert ;)) I'm not 100% certain that there are indeed issues here. Perhaps the original committer can comment (this was added in commit [3dde41]). Once I get confirmation that something indeed is suspect here I'll open a new ticket. The two key elements I kept wondering about were: 1. Whether the configure script is doing the correct thing in the case where the build environment (toolchain) contains *both* libnl2 and libnl3 (so libnl2 is available directly in <sysroot>/usr/include/netlink and libnl3 is available in <sysroot>/usr/include/libnl3/netlink). 2. The include directory is hardcoded as /usr/include/libnl3 and I'm wondering whether this will do the right thing in a cross-development environment (where the toolchain is something other than the default - i.e., non-standard sysroot). In my tests I was only able to resolve libnl3 symbols when -I<sysroot>/usr/include/libnl3 was added to the conftest.c compile. In my cases above <sysroot> is the install area for my cross-toolchain (e.g., /usr/local/x/y/toolchain...). Thanks, -David > Does anyone have an idea when the first v5.7.3 patch (v5.7.3.1) might > appear? > > Thanks, > -David > >> Thanks, >> Robert ------------------------------------------------------------------------------ Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ Net-snmp-coders mailing list Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
