In trying to manually determine the maximum transmission unit (MTU) of a triple IPsec encrypted link, I am using ICMP to form the basis. The MTU is not adding up correctly based on Wireshark output. The number of bytes adds up correctly but the displayed ICMP fields seem to be incorrect. And Wireshark includes two sequence number fields in the ICMP request and ICMP reply which does not folow the documented ICMP packet structure - OR did things change again and I'm still asleep :) ? The Ping request total bytes is 1314 bytes, correct The Ping reply total bytes is 1318 bytes, correct The extra fields displayed within each captured packet seems to be incorrect. ::::::::::::::::::::::: Win XP Pro with Service pack 2: C:>ping –n 1 –l 1272 –f –i 2 192.168.1.1 ::::::::::::::::::::::::: When I capture (Wireshark 1.4.4) the ICMP request and reply, I expect Wireshark to display: • Ethernet header • IP header • ICMP header and ICMP data When I expand the ICMP request header, I expect Wireshark to display: • Type field • Code • Checksum When I expand the ICMP reply header, I expect Wireshark to display: • Type field • Code • Checksum • Identifier • Sequence number BUT, instead I see the following: ICMP Type: 8 (Echo (ping) request) Code: 0 Checksum: 0x92c2 [correct] Identified: 0x200 Sequence number: 7680 (0xle00) Sequence number (LE): 30 (ox00le) Data (1272 bytes) :::::::::::::::::: ICMP Type: 0 (Echo (ping) reply) Code: 0 Checksum: 0x9ac2 [correct] Identified: 0x200 Sequence number: 7680 (0xle00) Sequence number (LE): 30 (ox00le) Data (1272 bytes) ::::::::::::::::::: This is the expected view of the ICMP packet as explained in TCP/IP Illistrated Vol. 1 as well as most web searches. Ping request: Ethernet header = 18 bytes IP header = 20 bytes ICMP header = 4 bytes The ICMP portion is expanded to reveal these fields: edited 16 Mar ‘11, 04:53 |
2 Answers:
There are no extra fields. The sequence number field is simply being displayed in both big and little endian format to make it easier to follow when those sequence numbers are incrementing from one ICMP echo request/reply to the next. The reason both formats are shown is because the fields are populated in either big or little endian format, depending upon the OS and there is no definitive way to tell which format it's in from the contents of the packet. answered 16 Mar '11, 11:20  cmaynard ♦♦ Ok Great, thanks for explaining what's happening here. : BUT, is there a way [in Wireshark] to disable all of the Wireshark generated extra fields so it would be easier to determine what is on the wire verses what Wireshark adds. : Thanks again n best regards Frank (22 Mar '11, 11:22) fsebera Not to my knowledge, there isn't. (22 Mar '11, 11:26) cmaynard ♦♦ |
Don't forget, Windows adds 8 bytes for the ICMP header. So if you send 1460 byte ICMP (-l 1460), you still have to account for 20 bytes of IP header and 8 bytes of ICMP header. So the IP packet will be 1488 bytes (1460 ICMP + 8 ICMP header + 20 IP header). Also, if you want to see the ICMP packet size, open up the ICMP header and add the ICMP data size as a column. One more thing, not everyone will send you an ICMP 3/4 message. So you may never be able to determine the MTU via Path-MTU Discovery. So your method of sending pings of varying size manually may be the only option. This is why Cisco routers offer you the hack option of munging the MSS field on the router (via tcp intercept) answered 23 Mar '11, 16:45  hansangb edited 23 Mar '11, 16:47 |
So what are the “extra fields” in question?