I have setup a nagios distributed monitoring system environment and i am able to send passive checks to Nagios server using send_nsca. When i look at the handshake between Nagios Client and Nagios Server, i see that Nagios Client is establishing a tcp connection to Nagios server whenever it has something to send and terminating the connection once the client is done sending the information. I want the tcp connection to stay up forever instead of terminating every time after data transfer is done. Could anyone please let me the know the process to make this happen?
You cannot do this without modifying the standard NSCA daemon. Normally, it will time out and that's why the NSCA client reestablishes the connection.
I've implemented send_nsca in both Perl and Ruby, and in both cases cannot make a persistent connection work.
A better solution, though, if you are using Nagios 3.x is to install the livestatus module (part of check_mk). This allows passive checks to be submitted, but supports a persistent connection and a whole lot more. We've moved to using this instead for many cases.
Related
I have written a basic TLS client for use in embedded systems (written in C). It uses TLS1.2, and it works great in 90% of situations. I have it working fine for HTTPS, and also have it working with various FTP servers using implicit and explicit FTPS. This week I've encountered an issue when using it with Cerberus FTP and proftpd though. TLS handshake goes through absolutely fine when opening the control channel on port 21, but when using passive mode and opening the passive port, my client sends the TLS Client hello (and I can see the server reply with a TCP ACK), but the FTP server never replies with a Server Hello. Does anyone know of a reason why that might be?-I'm guessing that there is something different in the way Cerberus and ProFTPd have implemented TLS that my client doesn't cater to. My client hello on both connections is identical (apart from port number in tcp headers) and I am not reusing the session data. I don't have this issue when testing against vsftpd or filezilla servers.
Found the reason for the lack of response, and it's an interesting one if anyone is ever writing their own FTP Client and need to use FTPS with it. The FTP Client I had written issued the PASV command, and then immediately opened the data channel port before then issuing the STOR command on the control channel. This behaviour is fine for all FTP servers when using un-encrypted FTP. However, as I discovered, you have to beware when using TLS. With proftpd and cerberus FTP, the FTP server doesn't seem to attach a listener to that port until you issue the STOR command (or equivalent), so it won't negotiate TLS on that port until you've issued the command, whereas other FTP servers like vsftpd and filezilla are happy to negotiate TLS as soon as the port is opened. SO the solution was to open the port after sending the STOR command.
I am working on a small application on an embedded platform which has to send some classified information to a server. This connection to the server is encrypted using SSL. The encryption is tunneled trough a proxy - in this case a Zentyal proxy. The embedded application is written in C and the connectivity part is done with wolfssl and lwip.
The application works fine with Zentyal 5.1. But recently the proxy server was updated to 6.1 and now the connection is falling all the time. Debugging the issue, I have found the problem occurs when the application ask the server for a tunnel connection. What I see happening is that the application sends the CONNECT request to the proxy ...
... to which the the proxy answers with a 200 Connection Established.
But after that packet is received the proxy send another message with Proxy-Coneection:Close. Whith has the effect that the connection is shut down before the SSL handshake.
I have tried different configuration in the Zentyal (transparent proxy enable, disable cache, etc.) but the error remains the same. Also, I have added different HTTP headers like proxy-connection: Keep alive. But the connection is still being closed.
Maybe this is a problem with the 6.1 version. I have tried looking through the change log but there is no reference to any change in the processing of the connect request. Neither are there any known problems related to the way the connect is being handled.
Any advice?
I am trying to connect from a NoMachine client on a Windows 7 machine to an OpenSUSE machine. I can only connect via NX however I keep running into Error 138:Connection Timed out. I can connect via SSH on my Command prompt however Seem to be unable to connect via here. Does anyone know a solution - been doing this since morning with no light in sight!
Routers supporting UPnP or NAT-PMP are configured automatically to pass connections to NoMachine and all required information is displayed at initial screen (Welcome to NoMachine).
Routers not supporting UPnP or NAT-PMP and Firewalls have to be configured manually to pass traffic to port 4000 (NX protocol), 22 (SSH protocol on Linux/MacOSX) or (4022) (SSH protocol on Windows).
So, check the configuration first.
I have a similar issue setting up my ftp server.
There are a couple of possibilities why the connection was not established, but in my case, and perhaps yours, you must allow the service you're trying to execute in your firewall settings.
In my case I allowed the ftp port and some other specific port for tcp communication.
This (and the proper service, router, etc setup) allowed the communication to be established.
My network team recently deployed Nexpose's Rapid 7. Unfortunately, every time they scan a SQL Server I typically see one of two severity 20 alerts being generated. This in turn causes SQL Server to SMS the on-call phone. I received hundreds of alerts last weekend.
I've googled every combination of nexpose, rapid 7, sql server, alerts, configuration settings, etc. I can think of to try to help the network team help me by not generating the errors, but can't find anything.
Has anyone else experienced this and, if so, were you able to resolve it?
The sev. 20 errors are:
Length specified in network packet payload did not match number of bytes read; the connection has been closed. Please contact the vendor of the client library.
The login packet used to open the connection is structurally invalid; the connection has been closed. Please contact the vendor of the client library.
We had a similar problem to this, it was happening when a web server was trying to connect to a MS SQL Server through the filewall. Instead of using the usual TCP/IP SQL Server connection that would run over port 1433 the web server was set to connect using Named Pipes, which use an SMB connection over port 445.
To get round it, we had the choice of allowing connections over port 445 or moving the connection to use port 1433.
This question has some useful information about the differences between these two types of connection.
If I can ping my DB server, is my SQL Server connection guaranteed to work?
I am using a default connection string in my code.
My program runs fine locally but overseas sites are having issues and I am wondering if SQL might be using a TCP or UDP port that is still blocked.
Here is the connection string "Data Source=xxxx.xxxx.com; Initial Catalog = xxxxx; User ID=xxxxx;password=xxxxx"
As far as I understand your question you are asking whether ICMP "ping" packet which returns guarantees you can open a connection on a particular TCP port? The answer is NO. It is also not the other way around - "ping" packets might be blocked by a firewall.
telnet xxxx.xxxx.com 1433 might be a better indicator.
No. The SQL Server Service must at least be running on the server for any mssql connections to work. The server itself can be up - running and pingable without the SQL Server Serice running.
You might also need to check whether the TCP/IP protocol is enabled using SQL Server Configuration Manager. Even when MSSQLSvc is running, it might not respond to remote requests.