Open xKevin04 opened 8 years ago
Interesting, I have never tried both actually... always one or the other :)
Will investigate
We have the same problem. Tried with versions 0.5.2.35 & 0.5.3.4. Solution is the same, only bind to either IPv4 or IPv6. Would love if you could investigate it further. Applies to 2008, 2012, 2106-servers. Log fills up with the following.
2018-05-29 22:00:41: error:c:\source\master\include\socket/server.hpp:255: Socket ERROR: Already open 2018-05-29 22:00:48: error:c:\source\master\include\socket/server.hpp:258: Failed to handle incoming connection: remote_endpoint: The file handle supplied is not valid 2018-05-29 22:01:01: error:c:\source\master\include\socket/server.hpp:258: Failed to handle incoming connection: remote_endpoint: The file handle supplied is not valid
Same here (Das angegebene Dateihandle ist ungültig
is translation of The file handle supplied is not valid
):
2018-07-20 08:29:23: error:c:\source\master\include\socket/server.hpp:255: Socket ERROR: Already open
2018-07-20 08:31:37: error:c:\source\master\include\socket/server.hpp:258: Failed to handle incoming connection: remote_endpoint: Das angegebene Dateihandle ist ungültig
2018-07-20 08:31:40: error:c:\source\master\include\socket/server.hpp:258: Failed to handle incoming connection: remote_endpoint: Das angegebene Dateihandle ist ungültig
We have the same probleme here.
Running v0.4.4.19 on Windows Server 2012 R2.
I tried setting up NSClient++ so that it accepts both the IPv4 and IPv6 address of our Naemon server. However, it seems that NSClient++ stops working properly when it receives both IPv4 and IPv6 connections. This results in a "Socket ERROR: Already open" and subsequent "Failed to handle incoming connection: remote_endpoint: File handle is not valid" errors.
Behaviour after such a socket error is not always the same: Sometimes, it doesn't handle any further connection at all. Sometimes, some checks continue to work. And sometimes it will crash.
Running in single mode, either IPv4 or IPv6, works perfectly. That is, as long as the service only listens for the respective protocol, or only gets connection attempts from one. So even if you configure it to allow an IPv4 address only, but still bind to IPv6 as well, incoming connections will kill the client. Swapping the addresses in the allowed hosts definition results in the same problem.
I also tried this on a second server and with the latest nightly v0.5.0.48, still not working. IP addresses in the following screenshot have been masked. You can see that the first couple of checks work, then as soon as checks of both protocols occurr simultaneously, it throws and error and finally crashes: