#17 Feature request:

[moeller0]

FreeBSD's traceroute for IPv4 (a different bninary from traceroute6) has a very interesting diagnostiuc/debug mode that allows to record and then analyse modification to the IP header along a path:
This -D option is described in the man page as:

-D      When an ICMP response to our probe datagram is received, print the differences between the transmitted packet and the packet quoted
             by the ICMP response.  A key showing the location of fields within the transmitted packet is printed, followed by the original packet
             in hex, followed by the quoted packet in hex.  Bytes that are unchanged in the quoted packet are shown as underscores.  Note, the IP
             checksum and the TTL of the quoted packet are not expected to match.  By default, only one probe per hop is sent with this option.

When used this looks like:

user@computer ~ % traceroute -aID -t 180 62.115.13.102               
traceroute to 62.115.13.102 (62.115.13.102), 64 hops max, 48 byte packets
 1  [AS0] 10.111.111.1 (10.111.111.1)  86.432 ms
vhtslen id  off tlprsum srcip   dstip   typ cod sum 
45b4300086490000010100000a6f6f063e730d66080071b6864800010000000000000000000000000000000000000000
____________________6d82________________________________________________________________________

 2  [AS6805] lo0-0.0001.prrx.01.ber.de.net.telefonica.de (62.52.192.120)  167.997 ms
vhtslen id  off tlprsum srcip   dstip   typ cod sum 
45b43000864a0000020100000a6f6f063e730d66080071b5864800020000000000000000000000000000000000000000
________________01__6d81________________________________

 3  [AS6805] gi2-2.02.xmws.99.agb.de.net.telefonica.de (62.53.11.182)  136.872 ms
vhtslen id  off tlprsum srcip   dstip   typ cod sum 
45b43000864b0000030100000a6f6f063e730d66080071b4864800030000000000000000000000000000000000000000
________________01__6d80________________________________________________________________________0000000000000000000000000000000000000000

 4  [AS6805] ae5-0.0001.corx.06.ham.de.net.telefonica.de (62.53.14.232)  139.277 ms
vhtslen id  off tlprsum srcip   dstip   typ cod sum 
45b43000864c0000040100000a6f6f063e730d66080071b3864800040000000000000000000000000000000000000000
________________01__6d7f________________________________________________________________________000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000020003fd600080101041f9b01

 5  [AS6805] gigabitethernet0-2-1-11.0002.dbrx.01.haj.de.net.telefonica.de (62.53.1.148)  65.223 ms
vhtslen id  off tlprsum srcip   dstip   typ cod sum 
45b43000864d0000050100000a6f6f063e730d66080071b2864800050000000000000000000000000000000000000000
________________01__6d7e________________________________________________________________________000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000020003fd600080101041f9b01

 6  [AS6805] gi0-0-1.90.rvhg.99.fra.de.net.telefonica.de (62.53.11.243)  70.117 ms
vhtslen id  off tlprsum srcip   dstip   typ cod sum 
45b43000864e0000060100000a6f6f063e730d66080071b1864800060000000000000000000000000000000000000000
________________01__6d7d________________________________________________________________________000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000020003fd600080101041f9b01

 7  [AS6805] bundle-ether2.0003.prrx.01.dus.de.net.telefonica.de (62.53.8.211)  60.707 ms
vhtslen id  off tlprsum srcip   dstip   typ cod sum 
45b43000864f0000070100000a6f6f063e730d66080071b0864800070000000000000000000000000000000000000000
________________01__6d7c________________________________________________________________________0000000000000000000000000000000000000000

 8  [AS12956] ae6-0-grtdusix1.net.telefonicaglobalsolutions.com (81.173.106.10)  63.025 ms
vhtslen id  off tlprsum srcip   dstip   typ cod sum 
45b4300086500000080100000a6f6f063e730d66080071af864800080000000000000000000000000000000000000000
________________01__6d7b________________________________

 9  *
10  [AS1299] ffm-b5-link.ip.twelve99.net (62.115.37.18)  62.515 ms
vhtslen id  off tlprsum srcip   dstip   typ cod sum 
45b43000865200000a0100000a6f6f063e730d66080071ad8648000a0000000000000000000000000000000000000000
__34____________01__6df9________________________________________________________________________0000000000000000000000000000000000000000

11  [AS1299] ffm-bb2-link.ip.twelve99.net (62.115.136.218)  75.121 ms
vhtslen id  off tlprsum srcip   dstip   typ cod sum 
45b43000865300000b0100000a6f6f063e730d66080071ac8648000b0000000000000000000000000000000000000000
__34____________01__6df8________________________________________________________________________0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000200039130008010164e24101

12  *
13  *
14  [AS1299] lax-b22-link.ip.twelve99.net (62.115.139.195)  210.335 ms
vhtslen id  off tlprsum srcip   dstip   typ cod sum 
45b43000865600000e0100000a6f6f063e730d66080071a98648000e0000000000000000000000000000000000000000
__00____________01__6e29________________________________________________________________________0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000200056910008010107648101

15  [AS1299] lax-b23-link.ip.twelve99.net (62.115.13.102)  210.816 ms
vhtslen id  off tlprsum srcip   dstip   typ cod sum 
45b43000865700000f0100000a6f6f063e730d66080071a88648000f0000000000000000000000000000000000000000
000000__0000____0000____00000000000000001415161718191a1b1c1d1e1f202122232425262728292a2b2c2d2e2f3031323334353637000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000200056910008010107648101

This is quite helpful to use traceroute as a tool to record IP header modifications along a path, in this case the original deciimal TOS value of 180 (0xb4: 10110100) got changed to 0x34:00110100 by hop 10. By only printing the values that differ from the original outgoing header it becomes trivial to see where things differ (the implementation is basic, so both the TTL and the checksum field differ as the comparison is always against the very first TTL=1 packet).

This would be a great feature especisally in combination with the already existing feature to set the TOS/tclass value.

While I believe this to be a useful feature generally, I am especially interested in the ability for normal end users to explore TOS/tclass (so DSCP and ECN bitfields) along network paths as there is little data and lots of opinions around what happends to TOS/DSCPs values over the internet.

Now, I understand if this is too esoteric a feature to contemplate, but I believe this coud empower users of your traceroute to learn even more relevant information about their networks and hence might still be a worthwhile addition?

[Dmitry Butskoy]

Sebastian Moeller wrote:

FreeBSD's traceroute for IPv4 (a different bninary from traceroute6)
has a very interesting diagnostiuc/debug mode that allows to record
and then analyse modification to the IP header along a path:

Unfortunately we don't have access to the raw IP headers anyway due to
implementation limitations.

All information is obtained only by the recvmsg(2) system call with the
MSG_ERRQUEUE flag set. This way allows unprivileged users to use "udp"
and/or "icmp/echo" traces without having to set the "setuid" bit on the
traceroute binary (or escalate privileges via setcap(8)). This was the
original reason why this traceroute implementation appeared in the first
place (the ability to run without setuid bits).

All we can do is check returned protocol headers (as has been done for
tcp mss clamping detection since 2.1.4), but NOT the returned IP header.
So it is imposibble to obtain the returned TOS value, since the Linux
kernel completely eats IP header before returning anything to us in
response to recvmsg(2). The only TOS value we can obtain (by IP_RECVTOS)
is the tos of the "icmp time exceeded" packet itself, not from the
incapsulated original packet.

This is quite helpful to use traceroute as a tool to record IP header
modifications along a path, in this case the original deciimal TOS
value of 180 (0xb4: 10110100) got changed to 0x34:00110100 by hop 10.
By only printing the values that differ from the original outgoing
header it becomes trivial to see where things differ

Yes, this would be a good feature, but it would require kernel support
to access encapsulated IP header. :(
ability for normal end users to explore TOS/tclass (so DSCP and ECN
bitfields) along network paths as there is little data and lots of
opinions around what happends to TOS/DSCPs values over the internet.
Maybe playing with TCP tracing will help here? At least for "ecn" cases?
(See "traceroute -T -O help" for more info, or traceroute(8)).