Ok, but what can I "send" and "receive" to/from the host?

I also tried old version of check_udp (that does not need any string), but I
read :
No data was recieved from host!
No response from host on port XX

Or simply:
No response from host on port XX

I see another strange situation. 
On port 161 I can use check_snmp (work correctly), but if I use check_udp on
port 161 it does not work at all !
How can be possible ?


-----Messaggio originale-----
Da: Andreas Ericsson [mailto:a...@op5.se] 
Inviato: martedì 3 settembre 2013 15:54
A: Nagios Users List
Cc: Marco Borsani
Oggetto: Re: [Nagios-users] check_udp error message

On 2013-09-03 12:33, Marco Borsani wrote:
> Hi all
> I need to control many UDP ports.
> I run the command:
> ./check_udp –H <IP_ADDRESS> –p 88
> I receive following error message (with state UNKNOWN) :
> With UDP checks, a send/expect string must be specified
> Can anyone help me to solve it?
> Those parameters should be optional..

UDP is a connection-less protocol. The "expect" string could indeed be
optional, and we could just expect to get something at all back when we send
something, but without sending anything we won't even touch the network, so
the remote host has no idea that we're trying to talk to it and we won't
know if the port is up.

That's why "send", at least, is not optional.

Andreas Ericsson                   andreas.erics...@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Considering the successes of the wars on alcohol, poverty, drugs and terror,
I think we should give some serious thought to declaring war on peace.

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!
Nagios-users mailing list
::: Please include Nagios version, plugin version (-v) and OS when reporting 
any issue. 
::: Messages without supporting info will risk being sent to /dev/null

Reply via email to