> -----Original Message-----
> From: Panther [mailto:saspurss / libero.it] 
> 
> Ok script is ok if I use Net::PingExternal.new.
> When ip address that I put is live script is ok, but when I 
> put into script a ip address wrong I don't know how to set a 
> timeout. I put timeout: 
> pe = Net::PingExternal.new("192.168.1.2", timeout="3")
> but it don't go, ping go go and I don't know how I can stop 
> it. How to set a timeout, so I have a string that say me (ip 
> address is not valid or I can't connect to it!!). TCP ping 
> unsuccessful: Connection refused - "connect(2)" UDP ping 
> unsuccessful: Connection refused - "recvfrom(2)" TCP adn UDP 
> say me that are not connect but PingExternal is ok. Isn't strange ??? 
> Thank you
> 

Hi Panther,

This is generally how I do things:

require "net/pingsimple"

################################################################
# The argument list is: host, port, timeout.
# The port is the "echo" port by default (usually 7)
# The timeout is 5 by default.
################################################################
udp = Net::PingUDP.new("192.168.1.2",7,5)

if udp.ping?
   puts "UDP ping successful"
   unless udp.warning.nil?
      puts "UDP Warning: " + udp.warning
   end
else
   puts "UDP ping error: " + udp.exception
end

If a timeout occurs, you should see something like, "execution expired".

As to why an external ping is successful and a UDP ping fails, your command
line ping uses icmp ping, not udp, so it's not the same thing.  If the host
is not running the appropriate echo service, it will be reported as
unreachable.  Check your inetd.conf file to verify.  In practice, I can
never get udp pings to work (on the default port anyway), using my own
module or Perl's Net::Ping, probably because most systems disable the udp
echo entry in the inetd.conf file.

As to why TCP isn't successful, that may have been an incorrect design
decision on my part.  Most ping programs assume that ECONNREFUSED represents
a successful ping.  However, it's *possible* that a wonky firewall setup
(like mine) could give you a false positive, since a router could block your
ping to the host and give you an ECONNREFUSED without actually pinging the
intended host (at least, that's what I suspect and that's what the experts
tell me).  The only way to tell for sure would be to include traceroute
information, which I'm not willing to do.

However, I'm willing to change the default behavior with regards to
ECONNREFUSED (or make it configurable) if that's what people want.

Regards,

Dan