On Thu, Dec 13, 2007 at 02:45:39PM +0000, Ian Jackson wrote: > thule:~# ping -w 120 -c 1 thule-3 > PING thule-3 (***.37.54) 56(84) bytes of data. > >From thule.uk.xensource.com (***.33.107) icmp_seq=1 Destination Host > >Unreachable > >From thule.uk.xensource.com (***.33.107) icmp_seq=2 Destination Host > >Unreachable > >From thule.uk.xensource.com (***.33.107) icmp_seq=3 Destination Host > >Unreachable > > --- thule-3 ping statistics --- > 3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2009ms > , pipe 3 > thule:~# ping -w 120 -c 1 thule-3 2>&1 | cat -vet > PING thule-3 (172.31.37.54) 56(84) bytes of data.$ > >From thule.uk.xensource.com (172.31.33.107) icmp_seq=1 Destination Host > >Unreachable$ > >From thule.uk.xensource.com (172.31.33.107) icmp_seq=2 Destination Host > >Unreachable$ > >From thule.uk.xensource.com (172.31.33.107) icmp_seq=3 Destination Host > >Unreachable$ > $ > --- thule-3 ping statistics ---$ > 3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2008ms$ > , pipe 3$ > thule:~# > > Observe the mysterious `, pipe 3' which looks like a bit of debugging > output.
The ", pipe 3" has actually been there all along, and I believe it's intentional. It is basically supposed to represent the number of outstanding echo requests that ping expects to be in transit at any given point. It's usually no greater than 1, in which case it's not included in the summary. It's normally set when the RTT is greater than the frequency with which requests are sent. In your case here, the kernel isn't generating the Host Unreachables until 3 requests have been sent, so it's set to 3. ping never shrinks the pipe value, so no matter how fast echo replies or errors come in once it's been set, it never can go back to 0. I don't believe it should be printing the pipe value in cases similar to the example you've provided... noah
signature.asc
Description: Digital signature
