On Fri, Sep 06, 2013 at 01:44:06PM +0200, Marco Borsani wrote: >I already have read that wiki...
OK, I'll try to explain in a different way. With a TCP-based service there's a standard handshake. You send a SYN, you get a SYN+ACK, you send an ACK; if that happens, the TCP port is open. (It may not be responding in a useful way, but it is at least accepting connections.) So check_tcp doesn't need anything more than an address and port number to be a useful generic monitor. With UDP there is no handshaking except what's defined in the application layer. If you send something that's not what the listening server expects, the response you get could be an error or could be nothing at all; it's entirely up to the listening server. The concept of an "open UDP port" is not really very meaningful in itself. You can check that you don't get an ICMP Port Unreachable when you send random junk to the port (I assume that's what the old check_udp is doing; I've never used it), but there are lots of reasons you might not get that packet back, including firewall policies; it's no sort of reliable test. So your UDP service, of which you still refuse to give any detail, is expecting something and will return something else. You need to send it that something, and look for the something else in the response -- just as you send a URL and look for body text when you're using check_http. Roger ------------------------------------------------------------------------------ Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58041391&iu=/4140/ostg.clktrk _______________________________________________ Nagios-users mailing list Nagios-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nagios-users ::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. ::: Messages without supporting info will risk being sent to /dev/null