Trouble with Net::Ping

[Ted Byers]

Here is a little script assembled fromt he documentation for
Net:ing.


use Net:ing;

$p = Net:ing->new();
$p->hires();
#$host = '192.168.2.1';
$host = 'www.google.ca';
print '$host: ',$host,"\n\n";
($ret, $duration, $ip) = $p->ping($host,50);
print $ret,"\n";
print $duration,"\n";
print $ip,"\n\n";
printf("$host [ip: $ip] is alive (packet return time: %.2f ms)\n",
1000 * $duration)
if $ret;
$p->close();

And here is the output from three runs of a program using Net:ing:

C:/Perl/bin\perl.exe -w k:/Work/test.network.pl
$host: 192.168.2.1

1
0.96875
192.168.2.1

192.168.2.1 [ip: 192.168.2.1] is alive (packet return time: 968.75 ms)

Compilation finished at Mon Dec 08 16:26:54
C:/Perl/bin\perl.exe -w k:/Work/test.network.pl
$host: www.google.ca

0
5
72.14.205.99


Compilation finished at Mon Dec 08 16:27:56

C:/Perl/bin\perl.exe -w k:/Work/test.network.pl
$host: www.google.ca

0
21.046875
72.14.205.99


Compilation finished at Mon Dec 08 16:29:48


The first is within my homeoffice LAN, 192.168.2.1 being the router.
The first two sets of output are without specifying a timeout (i.e.
using ($ret, $duration, $ip) = $p->ping($host)).

And now here is what I get using ping manually:

C:\>ping www.google.ca

Pinging www.l.google.com [72.14.205.103] with 32 bytes of data:

Reply from 72.14.205.103: bytes=32 time=17ms TTL=246
Reply from 72.14.205.103: bytes=32 time=14ms TTL=246
Reply from 72.14.205.103: bytes=32 time=14ms TTL=246
Reply from 72.14.205.103: bytes=32 time=16ms TTL=246

Ping statistics for 72.14.205.103:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 14ms, Maximum = 17ms, Average = 15ms

C:\>ping www.google.ca

Pinging www.l.google.com [72.14.205.99] with 32 bytes of data:

Reply from 72.14.205.99: bytes=32 time=17ms TTL=246
Reply from 72.14.205.99: bytes=32 time=17ms TTL=246
Reply from 72.14.205.99: bytes=32 time=17ms TTL=246
Reply from 72.14.205.99: bytes=32 time=17ms TTL=246

Ping statistics for 72.14.205.99:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 17ms, Maximum = 17ms, Average = 17ms

C:\>

The manual execution of ping happened just before and just after my
test scriptlet was executed.

So, then, why would my router invariably be seen by Net:ing as
accessable while google would not be, even though google clearly IS
accessable. Again, I tried other sites, such as Microsoft, and while
they are clearly accessable when manually invoking ping, the script
using Net:ing can not see them even though they get the correct IP
address for them (as can be determined by comparison with the manual
Ping command output at the time the script is executed.

Is there something in configuring Net:ing that can make it useful
for automating checking connectivity (in the context of handling
situations where, say, and LWP agent fails to retieve data as expected
- did we get no data because there was no data or because the
connection was lost or some other reason)?

Thanks

Ted

 

[Thrill5]

Here is a little script assembled fromt he documentation for
Net:ing.


use Net:ing;

$p = Net:ing->new();
$p->hires();
#$host = '192.168.2.1';
$host = 'www.google.ca';
print '$host: ',$host,"\n\n";
($ret, $duration, $ip) = $p->ping($host,50);
print $ret,"\n";
print $duration,"\n";
print $ip,"\n\n";
printf("$host [ip: $ip] is alive (packet return time: %.2f ms)\n",
1000 * $duration)
if $ret;
$p->close();

And here is the output from three runs of a program using Net:ing:

C:/Perl/bin\perl.exe -w k:/Work/test.network.pl
$host: 192.168.2.1

1
0.96875
192.168.2.1

192.168.2.1 [ip: 192.168.2.1] is alive (packet return time: 968.75 ms)

Compilation finished at Mon Dec 08 16:26:54
C:/Perl/bin\perl.exe -w k:/Work/test.network.pl
$host: www.google.ca

0
5
72.14.205.99


Compilation finished at Mon Dec 08 16:27:56

C:/Perl/bin\perl.exe -w k:/Work/test.network.pl
$host: www.google.ca

0
21.046875
72.14.205.99


Compilation finished at Mon Dec 08 16:29:48


The first is within my homeoffice LAN, 192.168.2.1 being the router.
The first two sets of output are without specifying a timeout (i.e.
using ($ret, $duration, $ip) = $p->ping($host)).

And now here is what I get using ping manually:

C:\>ping www.google.ca

Pinging www.l.google.com [72.14.205.103] with 32 bytes of data:

Reply from 72.14.205.103: bytes=32 time=17ms TTL=246
Reply from 72.14.205.103: bytes=32 time=14ms TTL=246
Reply from 72.14.205.103: bytes=32 time=14ms TTL=246
Reply from 72.14.205.103: bytes=32 time=16ms TTL=246

Ping statistics for 72.14.205.103:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 14ms, Maximum = 17ms, Average = 15ms

C:\>ping www.google.ca

Pinging www.l.google.com [72.14.205.99] with 32 bytes of data:

Reply from 72.14.205.99: bytes=32 time=17ms TTL=246
Reply from 72.14.205.99: bytes=32 time=17ms TTL=246
Reply from 72.14.205.99: bytes=32 time=17ms TTL=246
Reply from 72.14.205.99: bytes=32 time=17ms TTL=246

Ping statistics for 72.14.205.99:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 17ms, Maximum = 17ms, Average = 17ms

C:\>

The manual execution of ping happened just before and just after my
test scriptlet was executed.

So, then, why would my router invariably be seen by Net:ing as
accessable while google would not be, even though google clearly IS
accessable. Again, I tried other sites, such as Microsoft, and while
they are clearly accessable when manually invoking ping, the script
using Net:ing can not see them even though they get the correct IP
address for them (as can be determined by comparison with the manual
Ping command output at the time the script is executed.

Is there something in configuring Net:ing that can make it useful
for automating checking connectivity (in the context of handling
situations where, say, and LWP agent fails to retieve data as expected
- did we get no data because there was no data or because the
connection was lost or some other reason)?

Thanks

Ted

I've had issues with Net:ing being unreliable on Win32 systems as well.
Win32ingICMP is alternative if you don't need cross-platform support.

 

[Ted Byers]

That same documentation will show that Net:ing, by default, tries to
open a TCP socket to the destination.

Yes, I noticed that. I also noticed that the documentation said it
was the slowest because it is a higher level protocol than the others,
doing checks the others don't. My recollection is a bit fuzzy, but
IIRC TCP lives on top of UDP (and thus it makes sense that UDP would
be faster) and http lives on top of TCP. Since I would expect a web
client like a browser based on LWP would be using http exchanges, it
makes sense that if there is trouble with a given http exchange, one
should check the foundation it is built on, from the top down.

The ping command uses ICMP.

These are different Internet Protocols.

Yes, I know they're different protocols. But, as you note and I had
already observed, the documentation says tcp is the default protocol,
and that www.microsoft.com is generally alive but not icmp pingable.
That is why I tried the default TCP first.

But there is a problem, here, with what you've written. You say the
ping command uses ICMP, but you say www.microsoft.com is not ICMP
pingable. I used the ping command provided by MS with WXP. Why would
that use ICMP if www.microsoft.com is not ICMP pingable.

LWP itself will tell you that.  As noted, the "ping" command itself uses
ICMP - a protocol which would be of little use for data transfer, and
certainly not used by LWP.

I don't understand why you're on about ICMP when the documentation
says it is only one of three protocols, and the default protocol is
TCP.

In any event, LWP gives only a mention that a given transfer timed out
(and it happens only when trying to transfer a multimegabyte file),
but not why. I DID use the LWP:ebugFile package for this, but the
data doesn't seem very detailed.

I was, in fact, advised in this forum to check connectivity between
the machines in the transaction using ping and traceroute. I was
trying to learn how to use Net:ing in order to automatically check
connectivity between the machines involved in the dialog, and log the
results to a log file as well as email a report to myself should a
problem be detected.

I have yet to figure out how to get Net::Traceroute to install on my
machine, but CPAN would not install it or related packages on any of
the Windows machines I use. I guessed, from the error messages CPAN
provided that the reason it wouldn't install was that some of the
programs usually found on the various flavours of Unix don't exist on
WXP. I found a POE component (I don't recall the name of it off
hand), but the documentation for POE is daunting, making it seem that
that package is overkill. If I can't this to work reliably quickly, I
may just resort to using system to use the OS's pinging and route
tracing commands, such as they are, dumping what they write to stdout
to a file, and then just parse the file. There's more than one way to
skin a cat, as it were.

Thanks

Ted

 

[Ted Byers]

Here is a little script assembled fromt he documentation for
Net:ing.

use Net:ing;

$p = Net:ing->new();
$p->hires();
#$host = '192.168.2.1';
$host = 'www.google.ca';
print '$host: ',$host,"\n\n";
($ret, $duration, $ip) = $p->ping($host,50);
print $ret,"\n";
print $duration,"\n";
print $ip,"\n\n";
printf("$host [ip: $ip] is alive (packet return time: %.2f ms)\n",
1000 * $duration)
     if $ret;
$p->close();

And here is the output from three runs of a program using Net:ing:

C:/Perl/bin\perl.exe -w k:/Work/test.network.pl
$host: 192.168.2.1

1
0.96875
192.168.2.1

192.168.2.1 [ip: 192.168.2.1] is alive (packet return time: 968.75 ms)

Compilation finished at Mon Dec 08 16:26:54
C:/Perl/bin\perl.exe -w k:/Work/test.network.pl
$host:www.google.ca

Compilation finished at Mon Dec 08 16:27:56

C:/Perl/bin\perl.exe -w k:/Work/test.network.pl
$host:www.google.ca

Compilation finished at Mon Dec 08 16:29:48

The first is within my homeoffice LAN, 192.168.2.1 being the router.
The first two sets of output are without specifying a timeout (i.e.
using ($ret, $duration, $ip) = $p->ping($host)).

And now here is what I get using ping manually:

C:\>pingwww.google.ca

Pingingwww.l.google.com[72.14.205.103] with 32 bytes of data:

Reply from 72.14.205.103: bytes=32 time=17ms TTL=246
Reply from 72.14.205.103: bytes=32 time=14ms TTL=246
Reply from 72.14.205.103: bytes=32 time=14ms TTL=246
Reply from 72.14.205.103: bytes=32 time=16ms TTL=246

Ping statistics for 72.14.205.103:
   Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
   Minimum = 14ms, Maximum = 17ms, Average = 15ms

C:\>pingwww.google.ca

Pingingwww.l.google.com[72.14.205.99] with 32 bytes of data:

Reply from 72.14.205.99: bytes=32 time=17ms TTL=246
Reply from 72.14.205.99: bytes=32 time=17ms TTL=246
Reply from 72.14.205.99: bytes=32 time=17ms TTL=246
Reply from 72.14.205.99: bytes=32 time=17ms TTL=246

Ping statistics for 72.14.205.99:
   Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
   Minimum = 17ms, Maximum = 17ms, Average = 17ms

The manual execution of ping happened just before and just after my
test scriptlet was executed.

So, then, why would my router invariably be seen by Net:ing as
accessable while google would not be, even though google clearly IS
accessable.  Again, I tried other sites, such as Microsoft, and while
they are clearly accessable when manually invoking ping, the script
using Net:ing can not see them even though they get the correct IP
address for them (as can be determined by comparison with the manual
Ping command output at the time the script is executed.

Is there something in configuring Net:ing that can make it useful
for automating checking connectivity (in the context of handling
situations where, say, and LWP agent fails to retieve data as expected
- did we get no data because there was no data or because the
connection was lost or some other reason)?

Ted

I've had issues with Net:ing being unreliable on Win32 systems as well.
Win32ingICMP is alternative if you don't need cross-platform support.- Hide quoted text -

- Show quoted text -

Thanks. My scripts will be running on Windows, but the one server is
running Linux. I wouldn't think that would be a problem as long as
the machine is pingable. I have some familiarity with UDP and TCP.
Can you tell me how ICMP fits into the mix, and its relevance for http
exchanges?

Thanks

Ted

 

[Jim Gibson]

<[email protected]>, Ted

Thanks. My scripts will be running on Windows, but the one server is
running Linux. I wouldn't think that would be a problem as long as
the machine is pingable. I have some familiarity with UDP and TCP.
Can you tell me how ICMP fits into the mix, and its relevance for http
exchanges?

ICMP, TCP, and UDP are separate protocols that are part of the Internet
Protocol (IP) suite. You should probably start with a good book on
networking:

<http://www.kohala.com/start/>

or Wikipedia:

<http://en.wikipedia.org/wiki/Internet_Protocol>
<http://en.wikipedia.org/wiki/Internet_Control_Message_Protocol>
<http://en.wikipedia.org/wiki/User_Datagram_Protocol>
<http://en.wikipedia.org/wiki/Transmission_Control_Protocol>

HTTP uses TCP/IP for the transfer of static or dynamic web pages from a
web server to a browser/client.

 

[Peter J. Holzer]

Yes, I noticed that. I also noticed that the documentation said it
was the slowest because it is a higher level protocol than the others,
doing checks the others don't. My recollection is a bit fuzzy, but
IIRC TCP lives on top of UDP (and thus it makes sense that UDP would
be faster)

No. UDP and TCP are at the same level - both are layered on IP. Same for
ICMP although it is more tightly coupled to IP.

and http lives on top of TCP. Since I would expect a web
client like a browser based on LWP would be using http exchanges,

Maybe I'm mixing up threads, but didn't you have problems with FTP?
That's a different protocol then HTTP. Both use TCP, but you can't debug
either of them properly by trying to connect to TCP port 7 (which is
what Net:ing does).

it makes sense that if there is trouble with a given http exchange,
one should check the foundation it is built on, from the top down.

Yes, I know they're different protocols. But, as you note and I had
already observed, the documentation says tcp is the default protocol,
and that www.microsoft.com is generally alive but not icmp pingable.
That is why I tried the default TCP first.

But there is a problem, here, with what you've written. You say the
ping command uses ICMP, but you say www.microsoft.com is not ICMP
pingable. I used the ping command provided by MS with WXP. Why would
that use ICMP if www.microsoft.com is not ICMP pingable.

MS ping uses ICMP because that's its job. "ping" is the command which
checks if a host replies to ICMP echo requests. For some reason
Microsoft doesn't want its web servers to reply to ICMP echo requests.
Maybe they think you should use a browser to look at a webserver, not
ping ;-).

I don't understand why you're on about ICMP when the documentation
says it is only one of three protocols, and the default protocol is
TCP.

Probably to explain why it is possible that the ping command shows a
host as alive (that is it replies to ICMP echo requests) but Net:ing
doesn't (because a connection request to TCP port 7 (echo) times out),
or vice versa. They are just completely different protocols and a
firewall may block one but not the other. (Incidentally, if a firewall
does block requests with a port-unreachable message, Net:ing thinks
the host is alive, although it may be down).

In any event, LWP gives only a mention that a given transfer timed out
(and it happens only when trying to transfer a multimegabyte file),
but not why. I DID use the LWP:ebugFile package for this, but the
data doesn't seem very detailed.

I was, in fact, advised in this forum to check connectivity between
the machines in the transaction using ping and traceroute.

Yes. The commands "ping" and "traceroute". They already exist and are
almost certainly installed on your linux server. No need to write a
replacement in Perl.


hp

 

[Peter J. Holzer]

ping is a command that was written a long time ago. It was written
just to determine whether system A could connect to system B on a
single network, and the name comes from the fact that for each
successful packet sent a sound (ping) was emitted from the speaker of
the system it was running on so that he author could *hear* what was
happening as he wandered round the rest of the room checking physical
connexions (since he couldn't see the screen).

ping does have a "-a" option, but the name almost certainly comes from
the similarity to a submarine's sonar.

hp

 

[Ted Byers]

No. UDP and TCP are at the same level - both are layered on IP. Same for
ICMP although it is more tightly coupled to IP.

OK.

Maybe I'm mixing up threads, but didn't you have problems with FTP?
That's a different protocol then HTTP. Both use TCP, but you can't debug
either of them properly by trying to connect to TCP port 7 (which is
what Net:ing does).

Actually, I am having trouble with both. One script uses Net::FTP to
transfer archives from one of our servers to another across the
country, and the other uses LWP to retrieve a data feed from one of
our suppliers. Both work flawlessly when the amount of data is small
(up to a few hundred k) and both time out when the amount of data is
large (a few MB). Might it be that the client merely thinks the
connection has timed out but that the requested data is still being
transferred? I know that the script that pushes our large archives to
our other server does complete the transfer of the larger files (we
can open them and see they're intact), but then dies believing the
connection is broken and so never makes an attempt to send the next
file in thelist. We managed to work around this by opening the
connection to the ftp server just before trying to transfer a file and
closing it immediately after sending the file (something my colleague
- our system administrator - set up). It seems stupid to have to
close and reopen the ftp connection between large files, especially
when that is unnecessary with smal ones. Is there a better way?

WRT LWP, when the transfer fails, we work around it by recursively
partitioning the period for which we're requesting data into smaller
and smaller sub-intervvals until we get all the data. This is only
necessary when there is several MB worth of data to be retrieved.
Again, is there a better way?

MS ping uses ICMP because that's its job. "ping" is the command which
checks if a host replies to ICMP echo requests. For some reason
Microsoft doesn't want its web servers to reply to ICMP echo requests.
Maybe they think you should use a browser to look at a webserver, not
ping ;-).

OK. But that makes them unfriendly when one needs to check
connectivity.

Probably to explain why it is possible that the ping command shows a
host as alive (that is it replies to ICMP echo requests) but Net:ing
doesn't (because a connection request to TCP port 7 (echo) times out),
or vice versa. They are just completely different protocols and a
firewall may block one but not the other. (Incidentally, if a firewall
does block requests with a port-unreachable message, Net:ing thinks
the host is alive, although it may be down).

OK. That makes sense.

Yes. The commands "ping" and "traceroute". They already exist and are
almost certainly installed on your linux server. No need to write a
replacement in Perl.

OK. But the server running my script is Windows. There traceroute is
tracert (unless Windows Server uses a different name than the other
versions of Windows). And for the purpose of automating checking of
connectivity one would need a little extra code to invoke these OS
commands and parse the output to check for success or failure
(something I'd assumed was what Net:ing and Net::Traceroute were
made for, but it appears that was wrong).

Thanks

Ted

 

[Peter J. Holzer]

Actually, I am having trouble with both. One script uses Net::FTP to
transfer archives from one of our servers to another across the
country, and the other uses LWP to retrieve a data feed from one of
our suppliers. Both work flawlessly when the amount of data is small
(up to a few hundred k) and both time out when the amount of data is
large (a few MB). Might it be that the client merely thinks the
connection has timed out but that the requested data is still being
transferred? I know that the script that pushes our large archives to
our other server does complete the transfer of the larger files (we
can open them and see they're intact), but then dies believing the
connection is broken and so never makes an attempt to send the next
file in thelist.

Keep in mind that FTP uses at several connections: One control
connection (for the entire session) and one data connection per file
transfer. During a file transfer there is no traffic on the control
connection, so a firewall between the server and the client might drop
the connection in the meantime. This doesn't seem very probably since
your files are so small (only a few MB), and should be tranferred in a
few minutes at most, but it does match the symptoms your are having, and
your workaround:

We managed to work around this by opening the
connection to the ftp server just before trying to transfer a file and
closing it immediately after sending the file (something my colleague
- our system administrator - set up).

is what I would suggest in such a situation, unless you can fix the
firewall, or switch to a less baroque protocol (like SFTP, HTTP/WebDAV,
or rsync).

WRT LWP, when the transfer fails, we work around it by recursively
partitioning the period for which we're requesting data into smaller
and smaller sub-intervvals until we get all the data. This is only
necessary when there is several MB worth of data to be retrieved.

First of all, try to find out what the problem is:

Does the transfer work if you use some other tool (wget, curl, a web
browser, ...)? If not, it isn't a problem with LWP, and hence off-topic
for this newsgroup (it may become on-topic again, when the problem is
known, cannot be fixed and you need to implement a work-around). Do
large HTTP downloads from other sites work?

And remember: Always try to test exactly what you want to test. If you
want to test whether host A can reach host B, it makes no sense to run a
test on host C. If you are interested in HTTP, it makes no sense to use
ping, etc. Except as control experiments: If you have two experiments
where one works and one doesn't (e.g., you can transfer files from B to
C, but not from B to A), that difference is likely related to your
problem. But you need to be aware of the differences.

Again, is there a better way?

We can't know "a better way", since we don't know what the problem is.
It might be a problem in a perl module. But it might also be a problem
in one of the two firewalls or with your internet connection. Since your
problems with large (still small in my book) downloads occur with two
independent perl modules and maybe even other tools (you didn't say
whether the FTP download your system administrator set up uses perl or
something else) I'd guess that it's not the Perl modules.

OK. But that makes them unfriendly when one needs to check
connectivity.

They probably don't have any intention of being friendly for that
purpose.

(Personally I think blocking ICMP is stupid. I mean, if anybody is going
to attack www.microsoft.com, why should they try to ping them first?
They can attack the web server directly, they already know that it is there)

OK. But the server running my script is Windows.

Sorry, I was never sure which host did what and until this posting I
didn't even realize that you were talking about two different problems
(or two different symptoms of the same problem). You just aren't very
precise in your descriptions (and I don't want to ask more about your
network setup, since this is a Perl newsgroup, not a network newsgroup -
crosspost and fup to a more appropriate newsgroup if you want to
continue this discussion).

There traceroute is tracert (unless Windows Server uses a different
name than the other versions of Windows). And for the purpose of
automating checking of connectivity one would need a little extra code
to invoke these OS commands and parse the output to check for success
or failure (something I'd assumed was what Net:ing and
Net::Traceroute were made for, but it appears that was wrong).

I don't think anybody suggested that you should automate these tests.
Just do them once to see if you have basic connectivity (well, you
already know that) and how the route from one host to the other looks
like. They aren't all that helpful for your problem.

If you need continuous monitoring of connectivity, use a monitoring tool
like Nagios.

hp

 

[Mark L Pappin]

See
http://ftp.arl.mil/~mike/ping.html
for details of precisely when, why, and how.
(RIP Mike.)

ping does have a "-a" option, but the name almost certainly comes
from the similarity to a submarine's sonar.

Paragraph 2, sentence 1.

mlp