Your message dated Tue, 20 Sep 2011 21:13:39 +0200
with message-id <[email protected]>
and subject line Re: traceroute: please steal the BSD traceroute manpage
has caused the Debian Bug report #611469,
regarding traceroute: please steal the BSD traceroute manpage
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
611469: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=611469
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: traceroute
Version: 1:2.0.17-1
Severity: wishlist
Tags: upstream
Hi Daniel,
The traceroute manpage says, concerning its output format:
This program attempts to trace the route an IP packet would
follow to some internet host by launching probe packets with a
small ttl (time to live) then listening for an ICMP "time
exceeded" reply from a gateway. We start our probes with a ttl
of one and increase by one until we get an ICMP "port unreach‐
able" (or TCP reset), which means we got to the "host", or hit a
max (which defaults to 30 hops). Three probes (by default) are
sent at each ttl setting and a line is printed showing the ttl,
address of the gateway and round trip time of each probe. [...]
By contrast, FreeBSD's traceroute manpage says:
Tracking the route one's packets follow (or finding the
miscreant gateway that's discarding your packets) can be
difficult. Traceroute utilizes the IP protocol ‘time to live’
field and attempts to elicit an ICMP TIME_EXCEEDED response from
each gateway along the path to some host.
[...]
A sample use and output might be:
[yak 71]% traceroute nis.nsf.net.
traceroute to nis.nsf.net (35.1.1.48), 64 hops max, 38 byte packet
1 helios.ee.lbl.gov (128.3.112.1) 19 ms 19 ms 0 ms
2 lilac-dmc.Berkeley.EDU (128.32.216.1) 39 ms 39 ms 19 ms
3 lilac-dmc.Berkeley.EDU (128.32.216.1) 39 ms 39 ms 19 ms
[...]
11 nic.merit.edu (35.1.1.48) 239 ms 239 ms 239 ms
Note that lines 2 & 3 are the same. This is due to a buggy
kernel on the 2nd hop system - lilac-dmc.Berkeley.EDU - that
forwards packets with a zero ttl (a bug in the distributed
version of 4.3BSD). Note that you have to guess what path the packets
are taking cross-country since the NSFNet (129.140) doesn't supply
address-to-name translations for its NSSes.
Notice:
- explanation of purpose
- clear summary of how it works and how to use it
- examples
- related information for the puzzled reader
I would have appreciated all these things. :)
What do you think?
Jonathan
--- End Message ---
--- Begin Message ---
Jonathan,
please feel free to reopen when you've got it ready, closing the bug in
the meanwhile.
Thanks,
Daniel
--
Address: Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern
Email: [email protected]
Internet: http://people.progress-technologies.net/~daniel.baumann/
--- End Message ---
