09:58:19.220522 tun2 In IP6 (hlim 64, next-header ICMPv6 (58) payload length: 72) fd00:abcd:194:2::1 > fd00:abcd:194:2::100c: [icmp6 sum ok] ICMP6, echo reply, id 29771, seq 1
```
-
... so there's more length fields here (though still not more useful for the inside ICMPv6 packet), and especially the "UDP length 136" is shown to be "the UDP payload", +8 (UDP header) +20 (IPv4 header) will then result in `length 164` for the real packet being sent to the network. For IPv4, when running `tcpdump -vv`, the first line printed for each packet will show the overall size correctly.
+
... so there's more length fields here (though still not more useful for the inside ICMPv6 packet). For IPv4 UDP, one can now see that the "UDP, length 136" (second line) is "the UDP payload", to which +8 (UDP header) +20 (IPv4 header) are added to then result in `length 164` for the real packet being sent to the network (first line).
+
For IPv4, when running `tcpdump -vv`, the first line printed for each packet will show the overall size correctly.
This example has small packets, so no fragmentation, and no complications:
- We see one(1) ping packet go "tun2 Out" (so this is something "we send").
@@ 52,7 53,7 @@
### large packet in the tunnel ("ping -s 1452")
-
With the math above, we now know that `ping -s 1452` will now create a 1500 byte IPv6 packet "inside the tunnel" (1452 + 8 byte ICMP + 40 byte IPv6 header = 1500)
+
With the math above, we now know that `ping -s 1452 v6host` will now create a 1500 byte IPv6 packet "inside the tunnel" (1452 + 8 byte ICMP + 40 byte IPv6 header = 1500)
```
10:12:15.432260 tun2 Out IP6 (flowlabel 0xa3885, hlim 64, next-header ICMPv6 (58) payload length: 1460) fd00:abcd:194:2::100c > fd00:abcd:194:2::1: [icmp6 sum ok] ICMP6, echo request, id 31596, seq 1
@@ 72,8 73,8 @@
So this what we can observe
- one ICMPv6 ping packet "tun2 Out"
- *two* UDP packets going "enp3s0 Out" to the VPN server
-
- one is decoded as "UDP length 1524" (that is the UDP payload!), and "length 1500" on the wire - so something is missing
-
- the second one is decoded as "length 72" on the wire, and "ip-proto-17" inside
+
- one is decoded as "UDP length 1524" (that is the UDP payload!), and "length 1500" on the wire - so parts of the packet are missing
+
- the second one is decoded as "length 72" on the wire, and "ip-proto-17" inside - this is the rest
- when calculating "how many fragments and how big?" it needs to be taken into account that each fragment has its own IP header, so the "on the wire" sum of both fragments is larger than the "UDP payload 1524 + 1x UDP header + 1x IPv4 header" (1552) would lead you to expect
- *three* UDP packets coming in "enp3s0 In" from the Internet
