Page 1 of 1

Manual for custom TCP probes?

Posted: Thu May 06, 2010 12:07 pm
by ulliGT
Hi all!

I'm trying to configure some probes that check the availablity of services by connecting to it. Unfortunately a simple TCP connect is not always sufficient, e.g. when I want to check if the sharing on my file server is up and just do a TCP connect probe to port 445 (CIFS/SMB) it also returns the service as up when I disable the filesharing because the server still accepts TCP connections on port 445.

So configured a more detailed TCP probe like the HTTP probe that comes with the dude. I listened to my network traffic with wireshark and tried to figure out which commands to put into the 'send' and 'receive' fields in the probe configuration. But that does not work :-( probably because I'm using the wrong syntax or something. Rechecking with the HTTP probe I realized that there seem to be some variables one can use (HEAD?!) and that the TCP commands do not fully have to match the actual tranferred ones, e.g. 'HTTP GET / HTTP/1.1' also works as 'HEAD / HTTP/1.0\r\n\r\n' that is used in the probe.

Is there a manual for the configuration of extended TCP probes?

thank you!
ulli | hamburg | germany

Re: Manual for custom TCP probes?

Posted: Fri May 07, 2010 11:00 pm
by slech

Re: Manual for custom TCP probes?

Posted: Tue Oct 23, 2012 7:23 pm
by el berto
Maybe I'm a bit off-topic...

Is there a way to check Routerboard through TCP instead ping?
I've seen in Dude controls I can enable TCP probe (connect only or send/receive), but if target device is a routerboard, how can I do?
Maybe just simply check on port 80 at ip address of internal webpage of board?

Re: Manual for custom TCP probes?

Posted: Wed Oct 24, 2012 4:48 pm
by lebowski
That should probably work (grab the web page on port 80) but why not just grab the CPU counters from SNMP? If you make a SNMP request you know that many things must be working and if you only want to collect one statistic CPU is at least a much better indicator of performance than ping. Although I would agree that grabbing a web page indicates at least one more service is up and working fine.

On that note I am no HTTP expert so you will probably need more help but if you can get to the web page in question you can pick anything to match text in the "receive" field.
send: GET HTTP/1.1\r\n\r\n
Receive: Akamai

send: GET HTTP/1.0\r\n\r\n
Receive: Web

These work with no problem but sometimes you will see an http probe show "connection closed" although if you use wireshark it you will see the full conversation. One of many bugs I hope they fix.