I'm experiencing a serious net-snmp bug, Windows platform. This makes net-snmp
incorrectly report that port 162 is already opened by another process.
However, this is not the case. The actual problem is related to setsockopt.
This bug will occur on older versions of Windows, which don't allow
setsockopt to use the IP_RECVDSTADDR option. Even though it is #defined
in the header files.
My testing shows it doesn't work on Server 2003. I've also read comments
that it doesn't work on XP either. My fix uses the preprocessor. The
preprocessor approach may not be what you desire for a final solution.
But it's either that, or perform a runtime check for OS version.
The bug exists in:
/net-snmp/snmplib/transports/snmpUDPIPv4BaseDomain.c
The function is:
netsnmp_udpipv4base_transport
Here is one possible solution to the problem. Showing old/new code:
{ int sockopt = 1; if (setsockopt(t->sock, SOL_IP, IP_PKTINFO, &sockopt, sizeof sockopt) == -1) { DEBUGMSGTL(("netsnmp_udpbase", "couldn't set IP_PKTINFO: %s\n", strerror(errno))); netsnmp_transport_free(t); return NULL; } DEBUGMSGTL(("netsnmp_udpbase", "set IP_PKTINFO\n")); }
// changes
// old code
// #elif defined(IP_RECVDSTADDR)
// new code
// end changes
{
int sockopt = 1;
if (setsockopt(t->sock, IPPROTO_IP, IP_RECVDSTADDR, &sockopt, sizeof sockopt) == -1) {
DEBUGMSGTL(("netsnmp_udp", "couldn't set IP_RECVDSTADDR: %s\n",
strerror(errno)));
netsnmp_transport_free(t);
return NULL;
}
DEBUGMSGTL(("netsnmp_udp", "set IP_RECVDSTADDR\n"));
}
Submitted patch 1249. Patch does a Windows runtime test, which is more effective than this solution.
This post should be considered closed.
Last edit: Brice Breeden 2013-02-18