Trouble with Net::Ping

Discussion in 'Perl Misc' started by Ted Byers, Dec 8, 2008.

  1. Ted Byers

    Ted Byers Guest

    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
    Ted Byers, Dec 8, 2008
    #1
    1. Advertising

  2. Ted Byers

    Thrill5 Guest

    "Ted Byers" <> wrote in message
    news:...
    > 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.
    Thrill5, Dec 9, 2008
    #2
    1. Advertising

  3. Ted Byers

    Ted Byers Guest

    On Dec 8, 7:29 pm, Big and Blue <> 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, Dec 9, 2008
    #3
  4. Ted Byers

    Ted Byers Guest

    On Dec 8, 7:34 pm, "Thrill5" <> wrote:
    > "Ted Byers" <> wrote in message
    >
    > news:...
    >
    >
    >
    >
    >
    > > 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
    Ted Byers, Dec 9, 2008
    #4
  5. Ted Byers

    Jim Gibson Guest

    In article
    <>, Ted
    Byers <> 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
    Jim Gibson, Dec 9, 2008
    #5
  6. On 2008-12-09 06:14, Ted Byers <> wrote:
    > On Dec 8, 7:29 pm, Big and Blue <> 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, Dec 10, 2008
    #6
  7. On 2008-12-10 00:25, Big and Blue <> 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
    Peter J. Holzer, Dec 10, 2008
    #7
  8. Ted Byers

    Ted Byers Guest

    On Dec 10, 5:46 pm, "Peter J. Holzer" <> wrote:
    > On 2008-12-09 06:14, Ted Byers <> wrote:
    >
    > > On Dec 8, 7:29 pm, Big and Blue <> 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
    Ted Byers, Dec 11, 2008
    #8
  9. On 2008-12-11 21:34, Ted Byers <> wrote:
    > On Dec 10, 5:46 pm, "Peter J. Holzer" <> wrote:
    >> On 2008-12-09 06:14, Ted Byers <> 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
    Peter J. Holzer, Dec 13, 2008
    #9
  10. "Peter J. Holzer" <> writes:

    > On 2008-12-10 00:25, Big and Blue <> 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
    Mark L Pappin, Dec 16, 2008
    #10
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Fábio

    Ping in ASP.NET

    Fábio, Jul 2, 2003, in forum: ASP .Net
    Replies:
    1
    Views:
    498
    Fabio
    Jul 2, 2003
  2. Blinky the Shark

    [OT] Ping individual.net Subsrcibers

    Blinky the Shark, Mar 2, 2005, in forum: HTML
    Replies:
    7
    Views:
    468
    WebMaster
    Mar 3, 2005
  3. Zimmermann Christian

    Nettools ping / net view

    Zimmermann Christian, Feb 19, 2004, in forum: C++
    Replies:
    0
    Views:
    318
    Zimmermann Christian
    Feb 19, 2004
  4. Zimmermann Christian

    nettools ping / net view

    Zimmermann Christian, Feb 19, 2004, in forum: C++
    Replies:
    1
    Views:
    339
    Jens =?ISO-8859-1?Q?B=E4ckman?=
    Feb 19, 2004
  5. Daniel Berger

    [ANN] net-ping 1.2.0

    Daniel Berger, Dec 8, 2006, in forum: Ruby
    Replies:
    1
    Views:
    78
    Jos Backus
    Dec 9, 2006
Loading...

Share This Page