check_tcp strangeness

[phroggelator]

Does the -e option work correctly? Looking at the code I cant see any special reason why it wouldn't, but I haven't written C code for many years.

My problem is this. I have a service running on an unusual port that I need to check. When I connect to the service I get a particular response and I'd like to check for specific strings in that response. However, even though check_tcp claims to have read a certain number of bytes in the response the string I search is not found (even when I reduce it to a single character). It *looks* like check_tcp reads the response but is not copying the string correctly into the status variable, leaving it empty and therefore unable to match the string I look for. Here is what I run (normally we run 1.4.15, but this seems to also be the case in 2.0):

./check_tcp -v -w 5 -c10 -H XXXXXXXXXXXXXXX -p 1247 -d 2 -e R -E -s'\r\n\r\n'

which returns:

Using service TCP
Port: 1247
flags: 0xe
Send string:


server_expect_count: 1
0: R
looking for [R] anywhere in []
couldn't find it
received 326 bytes from host
#-raw-recv-------#

#-raw-recv-------#
TCP WARNING - Unexpected response from host/socket: |time=0.002900s;0.000000;0.000000;0.000000;3.000000

This is the same in both 1.4.15 and 2.0. I can see the code reading the correct response from the server when I run it in strace (including the string I'm expecting).

Am I missing something blindingly obvious?

Thanks

[sreinhardt]

I just tested this with a test server in C that I have that responds with "Hi new connection!" and it worked just fine for check_tcp looking for H or Hi. I used the your command to a T short of host, port, and expect string. I should note that I am testing on 2.0.1, but looking at our git commits, there are no recent changes to check_tcp.c or any of the supporting includes, that would seem to correct any issues. However comparing your output to my own, within #-raw-recv-------# I have the return string, whereas you do not seem to.

[phroggelator]

Hmmmm... well that makes it interesting. I'll try it with a 2.0.1 build and see wha happens. The response I get from the server is wrapped up in XML, though I cant see whay that might make a difference. FWIW I tried this from both the latest stable debian and RHEL servers with the same result. I'll let you know what happens.

[phroggelator]

After a bunch more testing it turns out that the the first three characters returned by the server (by protocol) is NUL.... This will of course break a few things. Thus the code is telling no lies when it says it cannot find the string. Is there any way to have the check_tcp strip unacceptable characters from the recieved data prior to checking for strings (or more precisely, any value to the larger community)? Or should I simply knock out some custom perl...

[tmcdonald]

If it is always the same 3 NUL characters (I assume you mean ASCII NUL 0x00, and not just a non-printing character) you could possibly just factor that into your expected response string. Not entirely sure how you would enter that into the command since it would likely see "\x00" as 4 literal characters to expect. Maybe use printf to pipe in the raw hex values?

[sreinhardt]

Oh, null bytes in the beginning, yep that definitely will cause some issues! I'm not sure that I feel it would be check_tcp's place to reformat the output from your server, especially since we wouldn't be able to get a string length from the server, and would instead have to rely on packet length, which could lead to buffer overruns. Let me discuss this with the other plugin developer, but I have a feeling he will agree, and point you towards the perl/custom modification of check_tcp.

Edit: After speaking with abrist, we agree that in cases like this, it would not be our place to alter the output of that server, and in fact while possible, it would likely lead to more issues than resolutions. We both also agree that perl or python would be an ideal case for this particular issue, due to C's handling of nulls in string functions.

[abrist]

Returning NULL will definitely break the plugin and is not consistent with the plugin guidelines. There is not a good way to handle this as stripping NULL bytes before loading a string *will* lead to overflows. What type of service returns NULL bytes on a port connection? Is it returning binary instead of a standard response?

[phroggelator]

My bad, I should have more explicit about it being 0x0 rather than just saying NUL. I pretty much figured it trying to strip silly chars would result in undesirable behaviour without a lot of effort, but it never hurts to ask. As to the protocol itself, having found the definiton document for it, it seems to have had some interesting design choices made in it. It claims to have a pure binary mode and an XML mode (which is what I've been exclusivley seeing), however they send the first 4 bytes as binary in all cases as a message length. The fact that this type of thing was widely and deeply discredited in the SMTP world 15+ years ago seems to have escaped the authors. This is an iRODS server for those that care.

TIme to knock out a quick perl script.

[abrist]

The fact that this type of thing was widely and deeply discredited in the SMTP world 15+ years ago seems to have escaped the authors.

No doubt.

TIme to knock out a quick perl script.

That is probably the best solution to this edge case. Hopefully this type of issue is truly rare.