Skip Menu |
 

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

Report information
The Basics
Id: 4170
Status: resolved
Priority: 0/
Queue: Net-Ping

People
Owner: Nobody in particular
Requestors: alexander.hartmaier [...] t-systems.at
bshreffler [...] dot.state.ny.us
Cc:
AdminCc:

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

Attachments
p



Subject: Net::Ping not multi-threadable
Download (untitled) / with headers
text/plain 428b
module: Net::Ping 2.31 perl: perl 5.8.0 (version included in redhat 8.0) os: Redhat 8.0 I need to ping multiple hosts (at the moment ~470) in a 1 minute interval. To realize this i create 4 threads (maybe more in the future) and use Net::Ping to ping them (as user root with icmp). Most of the time the hosts are reported to be reachable although they aren't! If I change the number of threads to 1 it works the way it should.
Date: Fri, 24 Oct 2003 14:34:35 -0600 (MDT)
From: Rob Brown <bbb [...] cpan.org>
To: Guest via RT <bug-Net-Ping [...] rt.cpan.org>
CC: Rob Brown <bbb [...] cpan.org>
Subject: Re: [cpan #4170] Net::Ping not multi-threadable
RT-Send-Cc:
Download (untitled) / with headers
text/plain 1.3k
Why didn't you use the "syn" proto instead of "icmp"? It can do hundreds of remote hosts simultanously by first sending out the SYN packets. Then it waits for the ACK packets. One working demonstration using this is here: http://search.cpan.org/~bbb/Net-Ping-2.31/demo/fping Unfortunately, it uses TCP protocol instead of ICMP at the network layer. If your routers do not permit TCP or if this is too much bandwidth, then this maybe not be appropriate for you. The nice thing is that you do not need to be root to use tNet::Ping's "syn" protocol. Plus, I'm not exactly clear what you mean by changing from 1 to 4 threads and how that affects the execution. -- Rob On Mon, 20 Oct 2003, Guest via RT wrote: Show quoted text
> This message about Net-Ping was sent to you by guest <> via rt.cpan.org > > Full context and any attached attachments can be found at: > <URL: https://rt.cpan.org/Ticket/Display.html?id=4170 > > > module: Net::Ping 2.31 > perl: perl 5.8.0 (version included in redhat 8.0) > os: Redhat 8.0 > > I need to ping multiple hosts (at the moment ~470) in a 1 minute interval. > To realize this i create 4 threads (maybe more in the future) and use Net::Ping to ping them (as user root with icmp). > > Most of the time the hosts are reported to be reachable although they aren't! > If I change the number of threads to 1 it works the way it should.
From: alexander.hartmaier [...] t-systems.at
Download (untitled) / with headers
text/plain 751b
@TCP SYN: If I use tcp syn packets the state tables of our firewalls are filled with new session entries which have a timeout of 2 hours. If I ping every minute that would result in 120 sessions PER HOST!!! Additionally not every device I have to monitor has an open tcp port. @ICMP: Why isn't an asyncronous way like it's with tcp syn/ack implemented for icmp too? @THREADS: I create multiple threads. Every thread reads of a Thread::Queue the hostnames which should be pinged and writes the reply into a thread-shared hash. If the thread count is one then the perl programm works the way it should. But if I increase the number of threads i always get reachable from the Net::Ping module regardless if the host is really responding or not.
Date: Fri, 7 Nov 2003 10:17:34 -0700 (MST)
From: Rob Brown <bbb [...] cpan.org>
To: Guest via RT <bug-Net-Ping [...] rt.cpan.org>
Subject: Re: [cpan #4170] Net::Ping not multi-threadable
RT-Send-Cc:
Download (untitled) / with headers
text/plain 2.1k
On Tue, 28 Oct 2003, Guest via RT wrote: Show quoted text
> @TCP SYN: If I use tcp syn packets the state tables of our firewalls > are filled with new session entries which have a timeout of 2 hours. > If I ping every minute that would result in 120 sessions PER HOST!!! > Additionally not every device I have to monitor has an open tcp port.
Then use a port that is NOT listening on the remote target host (like 1) in order to avoid filling up the firewall with session timeouts in the NAT tables. There has got to be a common port on all your remote devices that does NOT accept connections. Your goal is to try to get that "Connection refused" packet from each device. i.e.: $ telnet 10.0.0.47 1 Trying 10.0.0.47... telnet: connect to address 10.0.0.47: Connection refused $ Show quoted text
> @ICMP: Why isn't an asyncronous way like it's with tcp syn/ack > implemented for icmp too?
ICMP is terrible because it require root access to create the raw ICMP packets. If you really do have root access, then you can just use fping: http://www.fping.com/ It does all that simultaneous multiplexing you want and even uses ICMP protocol. fping 10.0.0.2 10.0.0.3 10.0.0.47 Here is my favorite one because it installs suid fping so even if you don't have root, you can still use it: rpm -Uvh ftp://rpmfind.net/linux/Mandrake/9.2/contrib/i586/fping-2.4b2-5mdk.i586.rpm But the biggest reason is because I am too unmotivated and lazy to code up the ICMP multiplexer since I have no use for that. I'm happy to accept your patches though. :-D Show quoted text
> @THREADS: I create multiple threads. Every thread reads of a > Thread::Queue the hostnames which should be pinged and writes the > reply into a thread-shared hash. > If the thread count is one then the perl programm works the way it > should. But if I increase the number of threads i always get reachable > from the Net::Ping module regardless if the host is really responding > or not.
I don't know what you mean by "threads" and I've never used Thread::Queue before, but that thread-shared hash sounds dangerous to me. I've used IPC::ShareLite before though. Sorry for my ignorance. Can you send me some sample code that exploits the bugs? -- Rob
From: steinar [...] skjelanger.com
Download (untitled) / with headers
text/plain 3.9k
[BBB - Fri Nov 7 12:18:09 2003]: Show quoted text
> Can you send me some sample code that exploits the bugs?
Hi! This example demonstrates the problems with Net::Ping and threads. A brief description of the code: 1. Create a Thread::Queue ($pingQueue) 2. Start two threads that blocks, waiting for ip addresses to appear in the $pingQueue. When an address is put on the queue, one of the threads uses Net::Ping to ping this address and print a success/failure message. When it's finished it blocks again, waiting for a new address. 3. Start a scheduler thread that puts four different ip addresses in the queue with $sleepTime seconds delay between them. ----------------------------------------------------------- #!perl -w use threads; use Thread::Queue; use Net::Ping; my $pingQueue = Thread::Queue->new; my $sleepTime = 5; # Start ping threads threads->new(\&pingThread); # ping thread #1 threads->new(\&pingThread); # ping thread #2 # Start scheduler thread threads->new(\&pingScheduler); # Idle main thread forever while(1) {} sub pingThread() { my $thread_id = threads->tid(); while ($ip_address = $pingQueue->dequeue) { $p = Net::Ping->new("icmp"); if (($p->ping($ip_address))) { print "($thread_id) Ping test OK : $ip_address\n"; } else { print "($thread_id) Ping test FAILED: $ip_address\n"; } undef($p); sleep(1); } } sub pingScheduler() { while(1) { $pingQueue->enqueue("192.168.0.201"); sleep($sleepTime); $pingQueue->enqueue("192.168.0.202"); # should timeout sleep($sleepTime); $pingQueue->enqueue("127.0.0.1"); sleep($sleepTime); $pingQueue->enqueue("192.168.0.203"); # should timeout sleep($sleepTime); } } ----------------------------------------------------------- On the computer I ran the tests below, the 1st and 3rd address were expected to return a reply, while the 2nd and 4th should timeout because they don't exist on this network. The numbers on the beginning of the lines are the IDs of the thread performing the ping. When $sleepTime is large enough (e.g. 15), each ping is guaranteed to have finished before the next one is started, and the results are as expected: D:\perlsrc>perl pingfail.pl (1) Ping test OK : 192.168.0.201 (2) Ping test FAILED: 192.168.0.202 (2) Ping test OK : 127.0.0.1 (2) Ping test FAILED: 192.168.0.203 (1) Ping test OK : 192.168.0.201 (2) Ping test FAILED: 192.168.0.202 (1) Ping test OK : 127.0.0.1 (2) Ping test FAILED: 192.168.0.203 (1) Ping test OK : 192.168.0.201 Terminating on signal SIGINT(2) With a $sleepTime of e.g. 5, things start to mess up: D:\perlsrc>perl pingfail.pl (1) Ping test OK : 192.168.0.201 (1) Ping test OK : 127.0.0.1 (2) Ping test OK : 192.168.0.202 (2) Ping test OK : 192.168.0.201 (1) Ping test OK : 192.168.0.203 (1) Ping test OK : 127.0.0.1 (2) Ping test OK : 192.168.0.202 (2) Ping test OK : 192.168.0.201 (1) Ping test OK : 192.168.0.203 (1) Ping test OK : 127.0.0.1 (2) Ping test OK : 192.168.0.202 Terminating on signal SIGINT(2) As far as I can see (from tracing the Ping.pm), this is what happens: 1. First ping of .0.201 is finished OK before the second ping is started. 2. The second ping (of .0.202) starts and waits for a timeout. 3. The third ping (of 127.0.0.1) is started, receives an immediate reply which is accepted as a valid response to the packet sent. The result is printed. 4. The thread of the second ping also sees the packet from 127.0.0.1, and also accepts it as a valid response to _it's_ packet (which it's clearly not). The wait for a timeout for .0.203 is interrupted in the same way when the next reply for .0.201 arrives. I would also like to see this module thread safe, but I'm not sure what's the best way to do it. Using an external program ping(1) or fping creates a lot of overhead because of all the extra processes that will be created and destroyed just to send a tiny packet? Regards, Steinar Skjelanger
From: alexander.hartmaier [...] t-systems.at
Download (untitled) / with headers
text/plain 387b
Fantastic Steinar! That's exactly what seems to be the problem! Because of this bug i now use python with my own implementation of async ping. It uses an array where all sequence number of sent packets are stored and dropped when an answer is received. I think the bug is in the receive code which should check the source ip, sequence number, id and checksum of the received packet.
From: Roy Evans
Download (untitled) / with headers
text/plain 713b
I have also hit this problem. Start off a bunch of threads , then do a ping in each thread & loop within each thread. This is on an old Solaris machine , 5.7 or so. in Ping.pm , I notice line 454 $nfound = mselect((my $rout=$rbits), undef, undef, $timeout); # Wait for packet - Which doesn't do what it says on the box, it doesn't wait and if I add a print onto the end of line 468 ($from_port, $from_ip) = sockaddr_in($from_saddr); print "Recv",$self-> {"fh"},&time(),&inet_ntoa($ip),&inet_ntoa($from_ip); I get results like : Recv FileHandle=GLOB(0x3afa930) 1088099619.891 10.191.253.33 10.182.253.50 ie, the read from the socket is picking up a ping response from another thread.
From: Roy Evans
Download (untitled) / with headers
text/plain 713b
I have also hit this problem. Start off a bunch of threads , then do a ping in each thread & loop within each thread. This is on an old Solaris machine , 5.7 or so. in Ping.pm , I notice line 454 $nfound = mselect((my $rout=$rbits), undef, undef, $timeout); # Wait for packet - Which doesn't do what it says on the box, it doesn't wait and if I add a print onto the end of line 468 ($from_port, $from_ip) = sockaddr_in($from_saddr); print "Recv",$self-> {"fh"},&time(),&inet_ntoa($ip),&inet_ntoa($from_ip); I get results like : Recv FileHandle=GLOB(0x3afa930) 1088099619.891 10.191.253.33 10.182.253.50 ie, the read from the socket is picking up a ping response from another thread.
From: stephen a polinsky dt org
Download (untitled) / with headers
text/plain 1.4k
[guest - Thu Jun 24 15:26:58 2004]: I've been working on fixing this in my own code for some time, and I think I've finally figured out what the problem is (this applies to using fork() too). What tipped me off is, even when creating ping packets with fork() and Net::Ping, all packet had the same IDENT field in the ICMP header. If you look at line 146, you'll see where the value for the identification field that goes in the ICMP header is generated. It's based on the process ID of the calling process. $self->{"pid"} = $$ & 0xffff; # Save lower 16 bits of pid The identification field and the sequence number are used to associate echo replies with requests. Here's where it's done in line 479: if (($from_pid == $self->{"pid"}) && .... ($from_seq == $self->{"seq"})) { So if all the identification fields in the echo requests are the same, there's really no way to associate each echo response with the proper request (strangely, source IP is not used). So we see inconsistent reporting of results. It finally occurred to me that since I was creating my instance of the ping class in my main program (not in the thread or child process), the identification field would be the same for all packets. So somewhere, you've got a line like: $ping = Net::Ping->new('icmp', 3); Move this into the thread or forked child, and a different identification field should be generated for each outbound echo request packet. This should solve the problem.
From: jjk [...] skism.org
Download (untitled) / with headers
text/plain 1.7k
[guest - Fri Mar 4 13:38:44 2005]: Show quoted text
> [guest - Thu Jun 24 15:26:58 2004]: > > I've been working on fixing this in my own code for some time, and I > think I've finally figured out what the problem is (this applies to > using fork() too). What tipped me off is, even when creating ping > packets with fork() and Net::Ping, all packet had the same IDENT field > in the ICMP header. > > If you look at line 146, you'll see where the value for the > identification field that goes in the ICMP header is generated. It's > based on the process ID of the calling process. > > $self->{"pid"} = $$ & 0xffff; # Save lower 16 bits of pid > > The identification field and the sequence number are used to associate > echo replies with requests. Here's where it's done in line 479: > > if (($from_pid == $self->{"pid"}) && .... > ($from_seq == $self->{"seq"})) { > > So if all the identification fields in the echo requests are the same, > there's really no way to associate each echo response with the proper > request (strangely, source IP is not used). So we see inconsistent > reporting of results. > > It finally occurred to me that since I was creating my instance of the > ping class in my main program (not in the thread or child process), the > identification field would be the same for all packets. > > So somewhere, you've got a line like: > > $ping = Net::Ping->new('icmp', 3); > > Move this into the thread or forked child, and a different > identification field should be generated for each outbound echo request > packet. This should solve the problem.
Creating new class instances will not work with ithreads. This hack prepends the current thread id (or 0 if not threaded) to the process id if the protocol is ICMP. This patch will not work with perl 5.005 threads. -Jeremy
From: jjk [...] skism.org
Download (untitled) / with headers
text/plain 1.7k
[guest - Fri Mar 4 13:38:44 2005]: Show quoted text
> [guest - Thu Jun 24 15:26:58 2004]: > > I've been working on fixing this in my own code for some time, and I > think I've finally figured out what the problem is (this applies to > using fork() too). What tipped me off is, even when creating ping > packets with fork() and Net::Ping, all packet had the same IDENT field > in the ICMP header. > > If you look at line 146, you'll see where the value for the > identification field that goes in the ICMP header is generated. It's > based on the process ID of the calling process. > > $self->{"pid"} = $$ & 0xffff; # Save lower 16 bits of pid > > The identification field and the sequence number are used to associate > echo replies with requests. Here's where it's done in line 479: > > if (($from_pid == $self->{"pid"}) && .... > ($from_seq == $self->{"seq"})) { > > So if all the identification fields in the echo requests are the same, > there's really no way to associate each echo response with the proper > request (strangely, source IP is not used). So we see inconsistent > reporting of results. > > It finally occurred to me that since I was creating my instance of the > ping class in my main program (not in the thread or child process), the > identification field would be the same for all packets. > > So somewhere, you've got a line like: > > $ping = Net::Ping->new('icmp', 3); > > Move this into the thread or forked child, and a different > identification field should be generated for each outbound echo request > packet. This should solve the problem.
Creating new class instances will not work with ithreads. This hack prepends the current thread id (or 0 if not threaded) to the process id if the protocol is ICMP. This patch will not work with perl 5.005 threads. -Jeremy
From: jjk [...] skism.org
Download (untitled) / with headers
text/plain 821b
Ooops! Here is the patch ---cut--- --- /usr/share/perl/5.8.7/Net/Ping.pm.orig 2003-06-27 17:31:07.000000000 -0400 +++ /usr/share/perl/5.8.7/Net/Ping.pm 2005-12-31 10:46:37.000000000 -0500 @@ -143,7 +143,9 @@ croak("icmp ping requires root privilege") if ($> and $^O ne 'VMS' and $^O ne 'cygwin'); $self->{"proto_num"} = (getprotobyname('icmp'))[2] || croak("Can't get icmp protocol by name"); - $self->{"pid"} = $$ & 0xffff; # Save lower 16 bits of pid + $self->{'pid'} = ( exists $::{'threads::'} && threads->self->tid ) ? threads->self->tid : 0; # are we are threaded? + $self->{'pid'} = $self->{'pid'} & 0xffff; $self->{"fh"} = FileHandle->new(); socket($self->{"fh"}, PF_INET, SOCK_RAW, $self->{"proto_num"}) || croak("icmp socket error - $!"); ---cut---
Subject: net::ping fails when used in conjunction with threads
Download (untitled) / with headers
text/plain 6.6k
net::ping does not work properly when run in multiple threads when a large number of nodes that it tries to ping are unreachable. In our network we have several thousand nodes of which about half are laptops and are typically not present on the network. In my testing, the attached script works perfectly if all nodes are present or only a very small percentage are unreachable. If however the list has a large number of unreachable nodes (I gave it 100 unreachable nodes right at the start of the list) then many reachable nodes are reported as unreachable. In my test it reported approximately 60 (reachable) nodes as unreachable before it recovered. In larger tests with thousands of nodes, of which approximately half are unreachable, the program will report that only at 10-20% of the reachable node are actually reachable. C:\MSU>perl -V Summary of my perl5 (revision 5 version 8 subversion 7) configuration: Platform: osname=MSWin32, osvers=5.0, archname=MSWin32-x86-multi-thread uname='' config_args='undef' hint=recommended, useposix=true, d_sigaction=undef usethreads=define use5005threads=undef useithreads=define usemultiplicity=define useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cl', ccflags ='-nologo -Gf -W3 -MD -Zi -DNDEBUG -O1 -DWIN32 -D_CONSOLE -DNO_STRICT -DHAVE_DE S_FCRYPT -DNO_HASH_SEED -DUSE_SITECUSTOMIZE -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLIO -DPERL_MSVCRT_READFIX', optimize='-MD -Zi -DNDEBUG -O1', cppflags='-DWIN32' ccversion='12.00.8804', gccversion='', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=undef, longlongsize=8, d_longdbl=define, longdblsize=10 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='__int64', lseeksize=8 alignbytes=8, prototype=define Linker and Libraries: ld='link', ldflags ='-nologo -nodefaultlib -debug -opt:ref,icf -libpath:"C:\Perl\lib\CORE" -ma chine:x86' libpth=\lib libs= oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib sh ell32.lib ole32.lib oleaut32.lib netapi32.lib uuid.lib ws2_32.lib mpr.lib winmm.lib version.lib od bc32.lib odbccp32.lib msvcrt.lib perllibs= oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.li b shell32.lib ole32.lib oleaut32.lib netapi32.lib uuid.lib ws2_32.lib mpr.lib winmm.lib version.li b odbc32.lib odbccp32.lib msvcrt.lib libc=msvcrt.lib, so=dll, useshrplib=yes, libperl=perl58.lib gnulibc_version='undef' Dynamic Linking: dlsrc=dl_win32.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' ' cccdlflags=' ', lddlflags='-dll -nologo -nodefaultlib -debug -opt:ref,icf -libpath:"C:\Perl\lib \CORE" -machine:x86' Characteristics of this binary (from libperl): Compile-time options: MULTIPLICITY USE_ITHREADS USE_LARGE_FILES USE_SITECUSTOMIZE PERL_IMPLICIT_CONTEXT PERL_IMPLICIT_SYS Locally applied patches: ActivePerl Build 815 [211909] Iin_load_module moved for compatibility with build 806 PerlEx support in CGI::Carp Less verbose ExtUtils::Install and Pod::Find instmodsh upgraded from ExtUtils-MakeMaker-6.25 Patch for CAN-2005-0448 from Debian with modifications Upgrade to Time-HiRes-1.76 25774 Keys of %INC always use forward slashes 25747 Accidental interpolation of $@ in Pod::Html 25362 File::Path::mkpath resets errno 25181 Incorrect (X)HTML generated by Pod::Html 24999 Avoid redefinition warning for MinGW 24699 ICMP_UNREACHABLE handling in Net::Ping 21540 Fix backward-compatibility issues in if.pm Built under MSWin32 Compiled at Nov 2 2005 08:44:52 @INC: C:/Perl/lib C:/Perl/site/lib use Net::Ping; use Net::Nslookup; use threads; use thread::queue; #use strict; #use warnings; my @RemoteNodes; # Array of remote node names to scan my $RemoteNodes; # Number of remote nodes to scan my $RemoteMachine; # my $IP; #IP address of remote machine my $threadcount = 4; # Number of threads for reading remote machine registries my $countdown = $threadcount; #Used to keep track of threads shutting down #Create queues my $NodeQ = new Thread::Queue; # Node names to be sacnned my $DataQ = new Thread::Queue; # Data structures returned by threads for output processing open (NODELIST, "$ARGV[0]") || die "Unable to open $ARGV[0]\n"; @RemoteNodes=<NODELIST>; $RemoteNodes = @RemoteNodes; print "Number of nodes to search = $RemoteNodes\n"; close (NODELIST); chomp(@RemoteNodes); # put all of the node names in the NodeQ foreach $RemoteMachine (@RemoteNodes) { $NodeQ->enqueue($RemoteMachine); } for (my $i = 0; $i <= $threadcount; $i++) { $NodeQ->enqueue("ZZZZZZ"); } #****************************************************************************** # Set up the threads that will read the remote machine registries #****************************************************************************** print "Starting threads\n"; my $thread1 = threads->create(processNode, 1); my $thread2 = threads->create(processNode, 2); my $thread3 = threads->create(processNode, 3); my $thread4 = threads->create(processNode, 4); while ($countdown > 0) { # Get a node name from the queue $result = $DataQ->dequeue; print "result $result\n"; if ($result eq "ZZZZZZ") { $countdown--; print "ML thread has shutdown, count down = $countdown\n"; } } print "ML all queues have stopped\n"; sub processNode { my $threadnum = $_[0]; print "In Thread $threadnum - processing\n"; my $RemoteMachine=$NodeQ->dequeue; $RemoteMachine=~tr/a-z/A-Z/; #Setup main loop and loop until we are told to quit my $quit = 0; my $p = Net::Ping->new(); if ($RemoteMachine eq "ZZZZZZ") { $quit = 1; } while ($quit == 0) { if ($p->ping($RemoteMachine)) # if remote machine responds to PING then { $return = ",answered ping,$threadnum"; } else { $return = ",did not respond to ping,$threadnum"; } $DataQ->enqueue("$RemoteMachine$return"); $RemoteMachine = $NodeQ->dequeue; $RemoteMachine=~tr/a-z/A-Z/; if ($RemoteMachine eq "ZZZZZZ") { $quit = 1; $DataQ->enqueue("ZZZZZZ"); } } $p->close(); print "exiting thread $threadnum\n"; }
From: jjk [...] skism.org
Download (untitled) / with headers
text/plain 437b
On Wed Jan 11 10:50:48 2006, guest wrote: Show quoted text
> net::ping does not work properly when run in multiple threads when a > large number of nodes that it tries to ping are unreachable. > > In our network we have several thousand nodes of which about half are > laptops and are typically not present on the network.
[text snipped] Show quoted text
> $p->close(); > print "exiting thread $threadnum\n"; > }
What version of Net::Ping are you using?
From: Carlos
Download (untitled) / with headers
text/plain 633b
Hi all, I am having the same exact issue with NET::PING and multi-thread. Any ideas in how to solve this problem? Regards, Carlos. On Seg. Out. 20 10:18:08 2003, guest wrote: Show quoted text
> module: Net::Ping 2.31 > perl: perl 5.8.0 (version included in redhat 8.0) > os: Redhat 8.0 > > I need to ping multiple hosts (at the moment ~470) in a 1 minute > interval. > To realize this i create 4 threads (maybe more in the future) and use > Net::Ping to ping them (as user root with icmp). > > Most of the time the hosts are reported to be reachable although they > aren't! > If I change the number of threads to 1 it works the way it should.
Download (untitled) / with headers
text/plain 621b
On Mon Oct 20 10:18:08 2003, guest wrote: Show quoted text
> module: Net::Ping 2.31 > perl: perl 5.8.0 (version included in redhat 8.0) > os: Redhat 8.0 > > I need to ping multiple hosts (at the moment ~470) in a 1 minute > interval. > To realize this i create 4 threads (maybe more in the future) and use > Net::Ping to ping them (as user root with icmp). > > Most of the time the hosts are reported to be reachable although they > aren't! > If I change the number of threads to 1 it works the way it should.
The patch in RT #17408 seems to resolve these problems. I'll be testing and should have another new release available today.
Download (untitled) / with headers
text/plain 786b
On Tue Jul 31 11:46:53 2007, SMPETERS wrote: Show quoted text
> On Mon Oct 20 10:18:08 2003, guest wrote:
> > module: Net::Ping 2.31 > > perl: perl 5.8.0 (version included in redhat 8.0) > > os: Redhat 8.0 > > > > I need to ping multiple hosts (at the moment ~470) in a 1 minute > > interval. > > To realize this i create 4 threads (maybe more in the future) and use > > Net::Ping to ping them (as user root with icmp). > > > > Most of the time the hosts are reported to be reachable although they > > aren't! > > If I change the number of threads to 1 it works the way it should.
> > The patch in RT #17408 seems to resolve these problems. I'll be testing > and should have another new release available today.
This problem appears to have been resolved with release 2.33. Thanks for the reports!


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.