TCPtest open connection issue 🔗 link

I'm having a problem with a spurious error reported by xymonnet on upgrading to 4.3.27:


Error output:
TCPtest error 1 seen on open connection for zo.cvs
TCPtest error 1 seen on open connection for °|.squid
TCPtest error 1 seen on open connection for  
v.squid
TCPtest error 1 seen on open connection for s.squid


If I substitute an earlier version of xymonnet (4.3.21), the error disappears. I put the 4.3.27 version back in, restart, and the errors return. There is nothing wrong with the hostname and these tests are not producing any 'real' errors. I am testing for a squid service on 5 hosts and cvs on one.


This has been reported in the dev forum, but has no published resolution:


    https://sourceforge.net/p/xymon/mailman/message/34900464


Has anyone else seen this issue?


thanks, Phil<mailto:user-8c58e1738592@xymon.invalid>

Hi Phil

On Thu, Apr 7, 2016 at 3:27 PM Phil Crooker <user-e8e31cd73303@xymon.invalid>

wrote:

TCPtest error 1 seen on open connection for žo.cvs

This is in some new code introduced in v4.3.25, to give more detailed
errors for some connected-but-fail error conditions when doing TCP tests.
Previously, it was a binary result: either the EXPECT string matched, or
the test failed in some way, without any indication as to why.  (You didn't
say if you've defined [cvs] and [squid] sections in protocols.cfg, but I'm
assuming you have.)

The error is probably benign - error 1 means timeout (although it's not
clear to me how a timeout condition can exist on a connected socket, but
maybe it's an expect error condition).  More importantly, the message
appears to be displaying a memory location that has not been initialised,
which suggests a stray or incorrectly-cast pointer is being used for the
hostname.

I think the offending bit of code (in xymonnet.c) is this:

    errprintf("TCPtest error %d seen on open connection for %s.%s\n",
tcptest->errcode, test->host, test->service->testname);

and should be something like this (untested):

    errprintf("TCPtest error %d seen on open connection for %s.%s\n",
tcptest->errcode, test->host->hostname, test->service->testname);

If you feel like testing this out, you can do so without replacing your
entire Xymon installation.  Simply adjust xymonnet.c and recompile, copy
the newly made xymonnet into /tmp/xymonnet, and adjust the CMD line in
tasks.cfg to use /tmp/xymonnet instead of xymonnet.

This won't stop the error message.  But instead you'll see the target
hostname in place of hieroglyphics.  To stop the message, you need to find
out what's causing the fault.  If this is happening on every test, you
might find something interesting in a packet dump.  Alternatively, check
the logs of the service at the other end to see if it tells you what the
problem is.

Cheers
Jeremy

From: Jeremy Laidman <user-71895fb2e44c@xymon.invalid>
Sent: Friday, 8 April 2016 10:11 AM
To: Phil Crooker; xymon at xymon.com
Subject: Re: [Xymon] TCPtest open connection issue

Hi Phil

On Thu, Apr 7, 2016 at 3:27 PM Phil Crooker <user-e8e31cd73303@xymon.invalid<mailto:user-e8e31cd73303@xymon.invalid>> wrote:

I'm having a problem with a spurious error reported by xymonnet on upgrading to 4.3.27:

Error output:

TCPtest error 1 seen on open connection for zo.cvs
TCPtest error 1 seen on open connection for ° |.squid
TCPtest error 1 seen on open connection for  v.squid
TCPtest error 1 seen on open connection for s.squid


If I substitute an earlier version of xymonnet (4.3.21), the error disappears. I put the 4.3.27 version back in, restart, and the errors return. There is nothing wrong with the hostname and these tests are not producing any 'real' errors. I am testing for a squid service on 5 hosts and cvs on one.

This is in some new code introduced in v4.3.25, to give more detailed errors for some connected-but-fail error conditions when doing TCP tests.  Previously, it was a binary result: either the EXPECT string matched, or the test failed in some way, without any indication as to why.  (You didn't say if you've defined [cvs] and [squid] sections in protocols.cfg, but I'm assuming you have.)

The error is probably benign - error 1 means timeout (although it's not clear to me how a timeout condition can exist on a connected socket, but maybe it's an expect error condition).  More importantly, the message appears to be displaying a memory location that has not been initialised, which suggests a stray or incorrectly-cast pointer is being used for the hostname.

I think the offending bit of code (in xymonnet.c) is this:

    errprintf("TCPtest error %d seen on open connection for %s.%s\n", tcptest->errcode, test->host, test->service->testname);

and should be something like this (untested):

    errprintf("TCPtest error %d seen on open connection for %s.%s\n", tcptest->errcode, test->host->hostname, test->service->testname);

If you feel like testing this out, you can do so without replacing your entire Xymon installation.  Simply adjust xymonnet.c and recompile, copy the newly made xymonnet into /tmp/xymonnet, and adjust the CMD line in tasks.cfg to use /tmp/xymonnet instead of xymonnet.

This won't stop the error message.  But instead you'll see the target hostname in place of hieroglyphics.  To stop the message, you need to find out what's causing the fault.  If this is happening on every test, you might find something interesting in a packet dump.  Alternatively, check the logs of the service at the other end to see if it tells you what the problem is.

Cheers
Jeremy

Hi Jeremy,

Yep, the test->host->hostname fixed the hostname problem (I had tried host->hostname before but didn't realise it was in test):


Error output:
TCPtest error 1 seen on open connection for host1.orix.com.au.cvs
TCPtest error 1 seen on open connection for host2.orix.com.au.squid
TCPtest error 1 seen on open connection for host3.orix.com.au.squid
TCPtest error 1 seen on open connection for host4.orix.com.au.squid


I found if I remove the "options banner" from the protocols.cfg entry, the TCPtest error goes away. The entries now just have the port number:


 [squid]
   port 3128


thanks Phil

On Fri, Apr 8, 2016 at 3:27 PM Phil Crooker <user-e8e31cd73303@xymon.invalid>

wrote:

Phil, so you were asking for a banner, but not sending anything?  This may
be your problem.  Both HTTP proxy and CVS protocols return nothing until
you send something.  Eventually it will time out and close the connection,
which may be why you received an error code "1" even though the socket
connected OK.  Perhaps try something like so (untested):

[squid]
   send "HEAD / HTTP/1.0\r\n\r\n"
   expect "HTTP/1.1"
   options banner
   port 3128

[cvs]
   send "BEGIN VERIFICATION REQUEST\n\nxymon\n\nEND VERIFICATION REQUEST\n"
   expect "I .... YOU"
   options banner
   port 2401

These "send" strings not only cause a normal squid/cvs server to close a
connection promptly, they also cause the server to send something that can
be displayed in the banner.

Cheers
Jeremy