#1249 Critical Win32 error. Due to setsockopt bug
Found a serious net-snmp bug, Windows platform. This bug causes the SNMP
process to prematurely exit on some Windows versions. The current code also outputs an
incorrect error message. Please fix.
SNMP incorrectly reports 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.
The patch includes a special runtime test for Windows OS version (<6).
Which is the only acceptable way to circumvent the problem.
The patch is a unified diff. So you'll have to "patch < mod.diff" it.
The bug exists in:
/net-snmp/snmplib/transports/snmpUDPIPv4BaseDomain.c
The function is:
netsnmp_udpipv4base_transport
NOTE: This bug was previously posted in 2438. Didn't see any response there, so I'm adding a patch. I'll try to close my old post. This post provides the correct solution.
Have you considered to use IP_PKTINFO instead of IP_RECVDSTADDR ? According to what I found on MSDN that should work on Windows XP (http://msdn.microsoft.com/en-us/library/windows/desktop/hh285668%28v=vs.85%29.aspx).
I'm not sure if you're on the net-snmp team or not. So I'll add more detail.
Were you expecting a patch with more features?
The existing preprocessor code is:
"if defined(linux) && defined(IP_PKTINFO)"
and within that
"elif defined(IP_RECVDSTADDR)"
So I assumed the net-snmp team had a reason for those tests. Such as supporting IP_PKTINFO only on Linux. There are also other posts regarding BSD and IP_RECVDSTADDR.
There are some issues with some of these socket options on Windows:
- they are poorly documented
- runtime doesn't always agree with documentation
- tend not to work uniformly, until you start using Server 2008 or later
- tend only to work on IPv4
I'm familiar with IP_RECVDSTADDR runtime behavior on Windows. And know from experience how it behaves. So this patch will work great on the Windows family to deal with IP_RECVDSTADDR.
NOTE:
If you're saying that you want a patch to properly support both IP_PKTINFO and IP_RECVDSTADDR for a Windows environment, then let me know.
I have access to the proper resources for that. HOWEVER, keep in mind that I'll have to rearrange net-snmp's preprocessor code to make that happen. My proposed solution will add a Windows-specific section, so that it won't interfere with Linux, the BSDs, etc.
Last edit: Brice Breeden 2013-02-19
The current preprocessor tests around the Net-SNMP recvfrom / sendto functions occur in at least eight different places and are inconsistent. I'm considering to replace all these tests by a single new preprocessor macro and to set that macro during the configure phase. That will make it much easier to change on which platforms e.g. IP_PKTINFO is used. I'm also considering to change "defined(linux) && defined(IP_PKTINFO)" into "defined(IP_PKTINFO)", at least if that doesn't break the Cygwin or MinGW builds.
Please clarify your objections against using IP_PKTINFO on Windows. A similar socket option, IPV6_RECVPKTINFO, is being used since a long time in the Windows port of ntpd, a widely used software package (see also http://www.ntp.org/downloads.html).
I'm not on the net-snmp dev team. Not objecting. My previous post doesn't say that.
I've seen some posts from you and others regarding these macros. Some of them as far back as 2011.
I don't object to using IP_PKTINFO and the IPv6 versions. Just saying that if I use that technique for Windows, I'd need to test on Windows XP/2003/7/2008 to validate the runtime behavior. Since I don't remember how they behave on all those Windows versions. And I wasn't sure who was posting on the forum.
When a program causes a process to prematurely exit. And causes an incorrect error message. Can't someone propose a short-term patch for it? I'm hoping the answer is yes.
The patch I'm proposing addresses a specific Windows issue. I agree it's not a permanent solution. And doesn't fix all "eight places" of the code. But don't you agree something must be done SOON?
It would be appreciated if you could test the Net-SNMP tree at http://github.com/bvanassche/net-snmp. There is a patch in that tree that makes Net-SNMP use IP_PKTINFO when built on Windows with Visual Studio or the compiler from the Windows SDK. The patches in that tree work fine here on Windows 7 (64-bit), Windows XP (32-bit), Linux and FreeBSD.
I'll test that tree next week, and let you know the results. Since you've tested 7 & XP, I'll test 2003/2008.
bvanassche,
Tested your tree on Win 2003, 2008, and 7. The Win 2003 problem is fixed. Thanks!
Any estimate regarding when your tree will be merged back into the main trunk?
Done :-)