Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

answered 2021-06-15 21:28:21 +0000

Chuckc gravatar image

Another protocol in the packet includes those fields.
An easy way to recreate this is to make a capture of a traceroute (tracert on Windows).
In this example I added -e frame.number which would help to inspect the packet in the Wireshark gui.

Intermediate devices will return a Type: 11 (Time-to-live exceeded) message that includes the IP header of the outgoing message. (see rfc792)

$ tshark.exe -r ./210615_traceroute.pcapng -T fields -E header=y -e frame.number -e ip.src -e ip.dst
frame.number    ip.src  ip.dst
1       192.168.200.135 8.8.8.8
2       192.168.200.1,192.168.200.135   192.168.200.135,8.8.8.8
3       192.168.200.135 8.8.8.8
4       192.168.200.1,192.168.200.135   192.168.200.135,8.8.8.8
5       192.168.200.135 8.8.8.8
6       192.168.200.1,192.168.200.135   192.168.200.135,8.8.8.8
7       192.168.200.135 8.8.8.8
8       192.168.10.111,192.168.200.135  192.168.200.135,8.8.8.8
9       192.168.200.135 8.8.8.8

Another protocol in the packet includes those fields.
An easy way to recreate this is to make a capture of a traceroute (tracert on Windows).
In this example I added -e frame.number which would help to inspect the packet in the Wireshark gui.

Intermediate devices will return a Type: 11 (Time-to-live exceeded) message that includes the IP header of the outgoing message. (see rfc792)

$ tshark.exe -r ./210615_traceroute.pcapng -T fields -E header=y -e frame.number -e ip.src -e ip.dst
frame.number    ip.src  ip.dst
1       192.168.200.135 8.8.8.8
2       192.168.200.1,192.168.200.135   192.168.200.135,8.8.8.8
3       192.168.200.135 8.8.8.8
4       192.168.200.1,192.168.200.135   192.168.200.135,8.8.8.8
5       192.168.200.135 8.8.8.8
6       192.168.200.1,192.168.200.135   192.168.200.135,8.8.8.8
7       192.168.200.135 8.8.8.8
8       192.168.10.111,192.168.200.135  192.168.200.135,8.8.8.8
9       192.168.200.135 8.8.8.8


Frame #1 left a system (.135) headed for Google (8.8.8.8) with a TTL of 1 which the gateway router (.1) decremented. The resulting value of 0 caused the router (.1) to send a ICMP Type 11 back in frame #2.
Frame #2 has a source of .1 (the router) and destination (.135) of the system making the traceroute request. The additional IP addresses in Frame #2 are the address from Frame #1 (the outgoing request).

traceroute does this three times (the * * * in traceroute output), increments the TTL and tries again.
Rinse and repeat in Frame #7 with a TTL of 2 which the 2nd hop (10.111) sends back.

Another protocol in the packet includes those fields.
An easy way to recreate this is to make a capture of a traceroute (tracert on Windows).
In this example I added -e frame.number which would help to inspect the packet in the Wireshark gui.

Intermediate devices will return a Type: 11 (Time-to-live exceeded) message that includes the IP header of the outgoing message. (see rfc792)

$ tshark.exe -r ./210615_traceroute.pcapng -T fields -E header=y -e frame.number -e ip.src -e ip.dst
frame.number    ip.src  ip.dst
1       192.168.200.135 8.8.8.8
2       192.168.200.1,192.168.200.135   192.168.200.135,8.8.8.8
3       192.168.200.135 8.8.8.8
4       192.168.200.1,192.168.200.135   192.168.200.135,8.8.8.8
5       192.168.200.135 8.8.8.8
6       192.168.200.1,192.168.200.135   192.168.200.135,8.8.8.8
7       192.168.200.135 8.8.8.8
8       192.168.10.111,192.168.200.135  192.168.200.135,8.8.8.8
9       192.168.200.135 8.8.8.8


Frame #1 left a system (.135) headed for Google (8.8.8.8) with a TTL of 1 which the gateway router (.1) decremented. The resulting value of 0 caused the router (.1) to send a ICMP Type 11 back in frame #2.
Frame #2 has a source of .1 (the router) and destination (.135) of the system making the traceroute request. The additional IP addresses in Frame #2 are the address addresses from Frame #1 (the outgoing request).

traceroute does this three times (the * * * in traceroute output), increments the TTL and tries again.
Rinse and repeat in Frame #7 with a TTL of 2 which the 2nd hop (10.111) sends back.

Another protocol in the packet includes those fields.
An easy way to recreate this is to make a capture of a traceroute (tracert on Windows).
In this example I added -e frame.number which would help to inspect the packet in the Wireshark gui.

Intermediate devices will return a Type: 11 (Time-to-live exceeded) message that includes the IP header of the outgoing message. (see rfc792)

$ tshark.exe -r ./210615_traceroute.pcapng -T fields -E header=y -e frame.number -e ip.src -e ip.dst
frame.number    ip.src  ip.dst
1       192.168.200.135 8.8.8.8
2       192.168.200.1,192.168.200.135   192.168.200.135,8.8.8.8
3       192.168.200.135 8.8.8.8
4       192.168.200.1,192.168.200.135   192.168.200.135,8.8.8.8
5       192.168.200.135 8.8.8.8
6       192.168.200.1,192.168.200.135   192.168.200.135,8.8.8.8
7       192.168.200.135 8.8.8.8
8       192.168.10.111,192.168.200.135  192.168.200.135,8.8.8.8
9       192.168.200.135 8.8.8.8


Frame #1 left a system (.135) headed for Google (8.8.8.8) with a TTL of 1 which the gateway router (.1) decremented. The resulting value of 0 caused the router (.1) to send a ICMP Type 11 back in frame #2.
Frame #2 has a source of .1 (the router) and destination (.135) of the system making the traceroute request. The additional IP addresses in Frame #2 are the addresses from Frame #1 (the outgoing request).

traceroute does this three times (the * * * in traceroute output), increments the TTL and tries again.
Rinse and repeat in Frame #7 with a TTL of 2 which the 2nd hop (10.111) sends back.back in Frame #8.