 | 1 | initial version |
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
| | 2 | No.2 Revision |
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.
| | 3 | No.3 Revision |
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.
| | 4 | No.4 Revision |
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.
Copyright Wireshark Foundation, 2017-2023 Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.
