Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   Perl Misc (http://www.velocityreviews.com/forums/f67-perl-misc.html)
-   -   Trouble with Net::Ping (http://www.velocityreviews.com/forums/t909156-trouble-with-net-ping.html)

Ted Byers 12-08-2008 09:47 PM

Trouble with Net::Ping
 
Here is a little script assembled fromt he documentation for
Net::Ping.


use Net::Ping;

$p = Net::Ping->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::Ping:

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::Ping 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::Ping 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::Ping 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 12-09-2008 12:34 AM

Re: Trouble with Net::Ping
 

"Ted Byers" <r.ted.byers@gmail.com> wrote in message
news:18195b92-3a9d-4fd2-aaa6-514ef6753fc0@k8g2000yqn.googlegroups.com...
> Here is a little script assembled fromt he documentation for
> Net::Ping.
>
>
> use Net::Ping;
>
> $p = Net::Ping->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::Ping:
>
> 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::Ping 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::Ping 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::Ping 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::Ping being unreliable on Win32 systems as well.
Win32:PingICMP is alternative if you don't need cross-platform support.




Ted Byers 12-09-2008 06:14 AM

Re: Trouble with Net::Ping
 
On Dec 8, 7:29*pm, Big and Blue <N...@dsl.pipex.com> wrote:
> Ted Byers wrote:
> > Here is a little script assembled fromt he documentation for
> > Net::Ping.

>
> That same documentation will show that Net::Ping, 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.

> > * * * *You may choose one of six different protocols to use forthe ping. The
> > * * * *"tcp" protocol is the default. Note that a live remote host may still
> > * * * *fail to be pingable by one or more of these protocols. For example,
> > * * * *www.microsoft.comis generally alive but not "icmp" pingable.

>
> 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.

> > Is there something in configuring Net::Ping 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)?

>
> 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::DebugFile 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::Ping 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 12-09-2008 06:17 AM

Re: Trouble with Net::Ping
 
On Dec 8, 7:34*pm, "Thrill5" <nos...@somewhere.com> wrote:
> "Ted Byers" <r.ted.by...@gmail.com> wrote in message
>
> news:18195b92-3a9d-4fd2-aaa6-514ef6753fc0@k8g2000yqn.googlegroups.com...
>
>
>
>
>
> > Here is a little script assembled fromt he documentation for
> > Net::Ping.

>
> > use Net::Ping;

>
> > $p = Net::Ping->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::Ping:

>
> > 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:\>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

>
> > 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::Ping 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::Ping 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::Ping 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::Ping being unreliable on Win32 systems as well.
> Win32:PingICMP 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 12-09-2008 06:08 PM

Re: Trouble with Net::Ping
 
In article
<26e50642-2b9f-4710-bd2b-02fef4b15a5e@41g2000yqf.googlegroups.com>, Ted
Byers <r.ted.byers@gmail.com> wrote:


> 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.

--
Jim Gibson

Peter J. Holzer 12-10-2008 10:46 PM

Re: Trouble with Net::Ping
 
On 2008-12-09 06:14, Ted Byers <r.ted.byers@gmail.com> wrote:
> On Dec 8, 7:29*pm, Big and Blue <N...@dsl.pipex.com> wrote:
>> Ted Byers wrote:
>> > Here is a little script assembled fromt he documentation for
>> > Net::Ping.

>>
>> That same documentation will show that Net::Ping, 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)


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::Ping 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.
>
>> > * * * *You may choose one of six different protocols to use for the ping. The
>> > * * * *"tcp" protocol is the default. Note that a live remote host may still
>> > * * * *fail to be pingable by one or more of these protocols. For example,
>> > * * * *www.microsoft.comis generally alive but not "icmp" pingable.

>>
>> 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.


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 ;-).


>> > Is there something in configuring Net::Ping 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)?

>>
>> 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.


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::Ping
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::Ping 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::DebugFile 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 12-10-2008 10:52 PM

Re: Trouble with Net::Ping
 
On 2008-12-10 00:25, Big and Blue <No_4@dsl.pipex.com> wrote:
> 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 12-11-2008 09:34 PM

Re: Trouble with Net::Ping
 
On Dec 10, 5:46*pm, "Peter J. Holzer" <hjp-usen...@hjp.at> wrote:
> On 2008-12-09 06:14, Ted Byers <r.ted.by...@gmail.com> wrote:
>
> > On Dec 8, 7:29*pm, Big and Blue <N...@dsl.pipex.com> wrote:
> >> Ted Byers wrote:
> >> > Here is a little script assembled fromt he documentation for
> >> > Net::Ping.

>
> >> That same documentation will show that Net::Ping, 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)

>
> 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.
> > 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::Ping 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?

>
>
>
> > 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.

>
> >> > * * * *You may choose one of six different protocols to use for the ping. The
> >> > * * * *"tcp" protocol is the default. Note that a live remote host may still
> >> > * * * *fail to be pingable by one or more of these protocols.. For example,
> >> > * * * *www.microsoft.comisgenerally alive but not "icmp" pingable.

>
> >> 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 thatwww.microsoft.comis 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 saywww.microsoft.comis not ICMP
> > pingable. *I used the ping command provided by MS with WXP. *Why would
> > that use ICMP ifwww.microsoft.comis 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 ;-).
>

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

> >> > Is there something in configuring Net::Ping 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)?

>
> >> 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.

>
> 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::Ping
> 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::Ping thinks
> the host is alive, although it may be down).
>


OK. That makes sense.
> > 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::DebugFile 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.
>

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::Ping and Net::Traceroute were
made for, but it appears that was wrong).

Thanks

Ted

Peter J. Holzer 12-13-2008 08:39 PM

Re: Trouble with Net::Ping
 
On 2008-12-11 21:34, Ted Byers <r.ted.byers@gmail.com> wrote:
> On Dec 10, 5:46*pm, "Peter J. Holzer" <hjp-usen...@hjp.at> wrote:
>> On 2008-12-09 06:14, Ted Byers <r.ted.by...@gmail.com> wrote:
>> > 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::Ping 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.


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.


>> > But there is a problem, here, with what you've written. *You say the
>> > ping command uses ICMP, but you saywww.microsoft.comis not ICMP
>> > pingable. *I used the ping command provided by MS with WXP. *Why would
>> > that use ICMP ifwww.microsoft.comis 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 ;-).
>>

> 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)


>> > 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::DebugFile 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.
>>

> 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::Ping 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 12-16-2008 11:50 PM

Re: Trouble with Net::Ping
 
"Peter J. Holzer" <hjp-usenet2@hjp.at> writes:

> On 2008-12-10 00:25, Big and Blue <No_4@dsl.pipex.com> wrote:
>> ping is a command that was written a long time ago.


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


All times are GMT. The time now is 12:48 PM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.