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 in Frame #8.