combined frames in icmp type 3
Hi
I am not sure if this is the right place to ask but i could use another opinion on a capture i am reviewing.
I am fighting with CenturyLink regarding some retransmit issues with RDP and a customer on their network
When i capture on my side when the customer is RDP'd into our services is an icmp destination unreachable (fragmentation needed) and then a bunch of retransmits.
the strange thing is the original packet length in the icmp message is higher than 1500 which is the mtu that is specified but none of the original packets are actually that length. What is even more puzzling to me is that it is actually reporting back the length of 2 frames that i am thinking were somehow combined at some point along the path.
I have attached a sample pcap
frames of interest that i am talking about are 26, 27, 28
26 has total length of 1500
27 has a total length of 273
totaling 1773
icmp states original frame is 1733
1773 - 40 for the striped headers of 26, and 27 = 1733
so that makes me think somewhere centurylink concatenated frame 26 and 27 for some reason?
Capture: https://tinyurl.com/y97oa9eq
Who's 'it' in '...is that it is actually reporting back the length of 2 frames...'
I came to the same conclusion as you. I would assume some router or rather a security device in the path to concatenate TCP payload of the frames in question into "dwarf jumbos", causing the next router to claim oversize, but actually already the sending machine itself may send these.
The thing is that network card drivers and the network stack are quite good in hiding jumbo frames from you even if they are indeed present on the wire, so the capture may not be verbatim. You may need to insert a switch supporting jumbo frames and counting frames separately for each range of sizes to confirm whether jumbo frames are being sent or not.
And as I write this, I remember I had a case where I was unable to RDP to a Windows machine on a LAN, and what I had to do was - guess what - to disable ...(more)