The philosophy of failed pings

Hi all,

I need some advice. I recently received a bug report for
Net::Ping::External class (part of
the net-ping package) where the user was getting false positives.

In his case he was pinging some bogus loopback address. The ping
command did not raise any error or warning, but it did have 100%
packet failure.

So, my question is, should I look for “100% packet loss” in the output
and, if found, consider that a failed ping no matter what? I know I
could make it configurable, but even if I go that route, I’d like to
know what the default behavior should be.

It wouldn’t be hard to implement, but I thought I would ask since I
think this package is fairly popular now I think and I want to get
feedback before I start breaking things.

Thanks,

Dan

100% loss sounds like an absolute failure to me, at least with a vanilla
“Is
it up?” situation.

On 3/16/07, Daniel B. [email protected] wrote:

Dan


“Hey brother christian with your high and mighty errand, Your actions
speak
so loud, I can’t hear a word you’re saying.”

-Greg Graffin (Bad Religion)

On 3/16/07, Daniel B. [email protected] wrote:

So, my question is, should I look for “100% packet loss” in the output
Dan

Normally I try to look it up myself, but right now I am a little bit
tired, sorry and man ping does not show the return values on my
Zenwalk :frowning:

I feel that you should go for maximum compatibility with the ping
system command.
So whenever ping leaves $? to 0 return true, else false.

The question remains: Which system? well I would opt for Linux b/c it
is probably the same as *BSD. But it is your project :slight_smile:

Just my 0.02…

Robert

On Mar 16, 2007, at 2:25 PM, Daniel B. wrote:

I need some advice. I recently received a bug report for
Net::Ping::External class (part of
the net-ping package) where the user was getting false positives.

In his case he was pinging some bogus loopback address. The ping
command did not raise any error or warning, but it did have 100%
packet failure.

I’m not sure I understand. Net::Ping::External#ping(host) was
returning true even though there was 100% packet loss to the host?

I don’t think #ping(host) should return true unless there has
actually been a packet returned from the targeted host.

Not sure if that answers your question though.

Gary W.

On 3/17/07, Daniel B. [email protected] wrote:

Yeah, the more I think about it, the more I’m leaning in that
direction.

This is probably silly, but ping isn’t that hard. Couldn’t you just
implement it with a raw socket? (Or supply both flavors, the ICMP and
the
UDP.) Then you’d have complete control over the outcome.

On Mar 17, 6:01 am, “Francis C.” [email protected]
wrote:

actually been a packet returned from the targeted host.

Not sure if that answers your question though.

Yeah, the more I think about it, the more I’m leaning in that
direction.

This is probably silly, but ping isn’t that hard. Couldn’t you just
implement it with a raw socket? (Or supply both flavors, the ICMP and the
UDP.) Then you’d have complete control over the outcome.

The net-ping package includes ICMP and UDP implementations (among
others). This is strictly for external pings that I’m referring to.

Anyway, I’m going to update it and put out a release sometime this
weekend hopefully. I need to get a Rakefile added as well.

Regards,

Dan

On Mar 16, 6:05 pm, Gary W. [email protected] wrote:

I’m not sure I understand. Net::Ping::External#ping(host) was
returning true even though there was 100% packet loss to the host?

Yes. In all of my past experiences when that happened there would be
some additional output sent to stderr, or something sent to stdout
that warned you something was wrong, and so my code relied on that. In
this particular case there was no warning or error.

I don’t think #ping(host) should return true unless there has
actually been a packet returned from the targeted host.

Not sure if that answers your question though.

Yeah, the more I think about it, the more I’m leaning in that
direction.

Regards,

Dan