Re: Re: A proposal for improvements to Net::Ping

Actually Item #1 doesn't make sense. That "connection refused" may be coming back from a firewall, not the host itself. So assuming that the host is up and pingable because a TCP connection to the echo port was refused is not appropriate.

In most cases the firewall will respond from its own IP address, however in the case of so-called "Layer 2 firewalls" or devices that are actually Ethernet bridges with proxy support for various protocols, the response may *appear* to have come from the host when in reality it came from another device on the network.

Having the module track whether the response was an active "connection refused" vs. just getting nothing back would be okay, but only the human being with the network map in front of them can determine if the response could have come from the host itself.

Nate

Comment on Re: Re: A proposal for improvements to Net::Ping

Replies are listed 'Best First'.
Re: Re: Re: A proposal for improvements to Net::Ping by rpc (Monk) on Mar 10, 2001 at 14:34 UTC
There are several techniques for using TCP to determine the status of a host. Advanced methods (see nmap and hping) require inspection of TCP headers and handshaking. Net::Ping relies on `connect()` only. I believe a revamp (maybe with Net::RawIP) would definitely be a good thing.	[reply] [d/l]
(tye)Re: A proposal for improvements to Net::Ping by tye (Sage) on Mar 10, 2001 at 12:41 UTC
The vast majority of firewall configurations I've run into won't return "connection refused" (actually I've never seen a firewall do that, but I'll take your word for it that some do). It is also possible to configure some filewalls so that they respond to pings (whether or not the device is up -- and I've actually seen this happen). So #1 makes as much sense as pinging does in my book. - tye (but my friends call me "Tye")	[reply]