Skip Menu |
 

This queue is for tickets about the Net-Ping CPAN distribution.

Report information
The Basics
Id: 27151
Status: stalled
Priority: 0/
Queue: Net-Ping

People
Owner: Nobody in particular
Requestors: ang [...] nmc-m.dtag.de
tom [...] stonehenge.com
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



CC: <bug-Net-Ping [...] rt.cpan.org>, <bbb [...] cpan.org>
MIME-Version: 1.0
X-Spam-Status: No, hits=0.0 required=8.0 tests=BAYES_50,DKIM_POLICY_SIGNSOME,DK_POLICY_SIGNSOME,SPF_PASS
X-Mailer: Microsoft Outlook, Build 10.0.2627
Received-SPF: pass (x1.develooper.com: domain of ang [...] nmc-m.dtag.de designates 194.25.15.217 as permitted sender)
Importance: Normal
content-type: text/plain; charset="utf-8"
Received: from la.mx.develooper.com (x1.develooper.com [63.251.223.170]) by diesel.bestpractical.com (Postfix) with SMTP id 634254D81DE for <bug-Net-Ping [...] rt.cpan.org>; Wed, 16 May 2007 09:01:21 -0400 (EDT)
Received: (qmail 12701 invoked by alias); 16 May 2007 13:01:21 -0000
Received: from isv1.nmc-m.dtag.de (HELO isv.nmc-m.dtag.de) (194.25.15.217) by la.mx.develooper.com (qpsmtpd/0.28) with ESMTP; Wed, 16 May 2007 06:01:07 -0700
Received: from isv.nmc-m.dtag.de (localhost [127.0.0.1]) by isv.nmc-m.dtag.de (Sendmail) with ESMTP id l4GD1069013701; Wed, 16 May 2007 15:01:01 +0200 (MEST)
Received: from nmc-m.dtag.de (spserv43.nmc-m.dtag.de [153.17.138.119]) by isv.nmc-m.dtag.de (Sendmail) with ESMTP id l4GD10ZJ013698; Wed, 16 May 2007 15:01:00 +0200 (MEST)
Received: from pcf1561 (pcf1561.nmc-m.dtag.de [153.17.131.12]) by nmc-m.dtag.de (Sendmail) with ESMTP id l4GD0x123426; Wed, 16 May 2007 15:00:59 +0200
Delivered-To: cpan-bug+net-ping [...] diesel.bestpractical.com
Subject: Net::Ping Bug found?
X-Msmail-Priority: Normal
Return-Path: <ang [...] nmc-m.dtag.de>
X-Original-To: bug-Net-Ping [...] rt.cpan.org
X-Spam-Check-BY: la.mx.develooper.com
X-Priority: 3 (Normal)
Date: Wed, 16 May 2007 15:01:00 +0200
Message-Id: <022d01c797ba$404bd010$0c831199 [...] nmcm.dtag.de>
X-Mimeole: Produced By Microsoft MimeOLE V6.00.2800.1896
To: <beginners [...] perl.org>
Content-Transfer-Encoding: quoted-printable
From: "Angerstein" <ang [...] nmc-m.dtag.de>
X-RT-Original-Encoding: iso-8859-1
Content-Length: 1416
Download (untitled) / with headers
text/plain 1.3k
Hi there! I am using Net::Ping on AIX (here 5.2) and I noticed a strange behaviour concerning the ICMP Payload Data Field. If I do a typical default ping with $p = new Net::Ping('icmp', $ping_timeout); I will get a EthernetII-IP-ICMP-Package (so far so good), but this package does not contain a Payload field (I would normaly expect), therefor it contains a Ethernet II Trailer (Wireshark). (I verified this by using iptrace v2.0 on aix and wireshark on my win2k desktop box.) If I do a ping with a manuell specified payload (like $p = new Net::Ping('icmp', $ping_timeout, 18);) the package looks (for me as a halfaway network geek) good. When is this a problem? It looks like some Router (by some Vendors) do not send icmp echo replies on such kind of requests. Sometimes it might look like that your router is down, but it isn´t. (And If you have like me over 1000 multivendor routers/switche/etc to manage, it´s not funny.) What could be the Problem: The package building process in Net::Ping is filthy-> I guess the IP-Total Length field is not set correctly (the payload lenght is not added to it). So Please: Could somebody verify this on her/his own System? If anybody feels able or have time to patch this, please patch the multithreadsupport patch right with it. (https://rt.cpan.org/Public/Bug/Display.html?id=4170) If you need to verify the fix feel free to ask me. Bastian Angerstein
CC: beginners [...] perl.org, bug-Net-Ping [...] rt.cpan.org, bbb [...] cpan.org
MIME-Version: 1.0
In-Reply-To: <022d01c797ba$404bd010$0c831199 [...] nmcm.dtag.de>
X-Spam-Status: No, hits=-2.6 required=8.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VERIFIED,DK_POLICY_SIGNSOME,DK_SIGNED,SPF_PASS
Content-Disposition: inline
Received-SPF: pass (x1.develooper.com: domain of tom.phoenix [...] gmail.com designates 66.249.82.225 as permitted sender)
References: <022d01c797ba$404bd010$0c831199 [...] nmcm.dtag.de>
content-type: text/plain; charset="utf-8"; format="flowed"
Received: from la.mx.develooper.com (x1.develooper.com [63.251.223.170]) by diesel.bestpractical.com (Postfix) with SMTP id 36D674D8241 for <bug-Net-Ping [...] rt.cpan.org>; Wed, 16 May 2007 12:38:16 -0400 (EDT)
Received: (qmail 26926 invoked by alias); 16 May 2007 16:38:15 -0000
Received: from wx-out-0506.google.com (HELO wx-out-0506.google.com) (66.249.82.225) by la.mx.develooper.com (qpsmtpd/0.28) with ESMTP; Wed, 16 May 2007 09:38:03 -0700
Received: by wx-out-0506.google.com with SMTP id s19so266983wxc for <bug-Net-Ping [...] rt.cpan.org>; Wed, 16 May 2007 09:37:57 -0700 (PDT)
Received: by 10.90.71.3 with SMTP id t3mr8315150aga.1179333477077; Wed, 16 May 2007 09:37:57 -0700 (PDT)
Received: by 10.90.113.16 with HTTP; Wed, 16 May 2007 09:37:57 -0700 (PDT)
Delivered-To: cpan-bug+net-ping [...] diesel.bestpractical.com
Subject: Re: Net::Ping Bug found?
Return-Path: <tom.phoenix [...] gmail.com>
Domainkey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=Vz0R/HPIZIG854ufu1nngamO1LRHyTydF9OCnVRCAIDyVpHKXZ2/CiB2vHWrg9qNo9P9O/HHz+3nDRKTkxCISaL2QtA0SmMvzDn48HH6eenUxN13P5vyR5jaH6JIN0jciiyxJV7jFnVUba0x3YLQ/UkwBHOgOyqBh6/uPyWYH1I=
X-Original-To: bug-Net-Ping [...] rt.cpan.org
X-Spam-Check-BY: la.mx.develooper.com
Dkim-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=eXpkmRRlsk/xCC5Q+VIMxOu2tDdQ7U4o54kmBO7iK1e4Dd0RKPkleoW5n7QWNQkEwviZeqnNLuTbfICnYRM2o4lJErtkElzQNPmscXiwyvGvkKb/PbY0ixowARX4E3dGLgbS83vb24snGGSfa0/Am8vQd9Zyb45KGSHgY5mqb3k=
X-Google-Sender-Auth: 345f73ac9ce03e22
Date: Wed, 16 May 2007 09:37:57 -0700
Sender: tom.phoenix [...] gmail.com
Message-Id: <31086b240705160937m3ee8a0bbk4c4a28e3b03a1e19 [...] mail.gmail.com>
To: Angerstein <ang [...] nmc-m.dtag.de>
Content-Transfer-Encoding: 7bit
From: "Tom Phoenix" <tom [...] stonehenge.com>
X-RT-Original-Encoding: ISO-8859-1
Content-Length: 327
Download (untitled) / with headers
text/plain 327b
On 5/16/07, Angerstein <ang@nmc-m.dtag.de> wrote: Show quoted text
> So Please: > Could somebody verify this on her/his own System?
I'm sure that many people will be glad to help you. Could you please supply a small program that testers could run and send you the output? Good luck with your project! --Tom Phoenix Stonehenge Perl Training
MIME-Version: 1.0
In-Reply-To: <022d01c797ba$404bd010$0c831199 [...] nmcm.dtag.de>
X-Mailer: MIME-tools 5.418 (Entity 5.418)
Content-Disposition: inline
Message-Id: <rt-3.6.HEAD-6048-1186591912-378.27151-0-0 [...] rt.cpan.org>
References: <022d01c797ba$404bd010$0c831199 [...] nmcm.dtag.de>
Content-Type: text/plain; charset="utf8"
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Original-Encoding: utf-8
Content-Length: 1693
Download (untitled) / with headers
text/plain 1.6k
On Wed May 16 09:01:33 2007, ang@nmc-m.dtag.de wrote: Show quoted text
> Hi there! > > I am using Net::Ping on AIX (here 5.2) and I noticed a strange behaviour > concerning the ICMP Payload Data Field. > > If I do a typical default ping with > $p = new Net::Ping('icmp', $ping_timeout); > I will get a EthernetII-IP-ICMP-Package (so far so good), > but this package does not contain a Payload field (I would normaly > expect), > therefor it contains a Ethernet II Trailer (Wireshark). > > (I verified this by using iptrace v2.0 on aix and wireshark on my win2k > desktop box.) > > If I do a ping with a manuell specified payload > (like $p = new Net::Ping('icmp', $ping_timeout, 18);) > the package looks (for me as a halfaway network geek) good. > > When is this a problem? > It looks like some Router (by some Vendors) do not send icmp echo > replies on such kind of requests. > Sometimes it might look like that your router is down, but it isn´t. > (And If you have like me over 1000 multivendor routers/switche/etc to > manage, > it´s not funny.) > > What could be the Problem: > The package building process in Net::Ping is filthy-> I guess > the IP-Total Length field is not set correctly (the payload lenght is > not added to it). > > So Please: > Could somebody verify this on her/his own System? > > If anybody feels able or have time to patch this, please patch the > multithreadsupport patch right with it. > (https://rt.cpan.org/Public/Bug/Display.html?id=4170) > > If you need to verify the fix feel free to ask me. > > Bastian Angerstein >
Can you please provide a code sample that demonstrates the problem? Without it, its very difficult to guess what the problem might be.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.