Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-users: Re: [Wireshark-users] Identification of Fragmented UDP Packets

From: Guy Harris <guy@xxxxxxxxxxxx>
Date: Thu, 21 Jan 2010 11:40:30 -0800
On Jan 21, 2010, at 11:08 AM, Eddie wrote:

> LAN IP headers:
> 
> 45

Version/IHL - version 4, 20 bytes.

> 00

Type of Service

> 05 14

Total length - 1300 bytes (1280 bytes of IP payload)

> 05 d7

Identification - 0x05d7

> 20 00

Flags and Fragment Offset: More Fragments, fragment offset = 0

> 80

Time to Live

> 11

Protocol - 17=UDP

> f3 f9

Header Checksum

> c0 a8 00 1e

Source Address

> 0010   ab a1 af a0

Destination Address

> 0000   45

Version/IHL

> 00

Type of Service

> 03 c0

Total length - 960 bytes (940 bytes of IP payload)

> 05 d7

Identification - 0x05d7, same as the previous fragment (which is as it should be)

> 00 a0

Flags and Fragment Offset: fragment offset=160=160*8 bytes=1280 bytes (which is as it should be, as that's the length of the previous fragment's payload)

> 80

Time to Live

> 11

Protocol - 17=UDP

> 14 ae

Header Checksum

> c0 a8 00 1e

Source Address - same as the previous fragment (which is as it should be)

> 0010   ab a1 af a0

Destination Address - same as the previous fragment (which is as it should be)

> WAN IP headers
> 
> 45

Version/IHL

> 00

Type of Service

> 05 dc

Total length - 1500 bytes (1480 bytes of IP payload)

> 36 98

Identification - 0x3698

> 20 00

Flags and Fragment Offset: More Fragments, fragment offset = 0

> 7f

Time to Live

> 11

Protocol - 17=UDP

> a7 46

Header Checksum

> 62 94 7a 5c

Source Address

> ab a1 af a0

Destination Address

> 45

Version/IHL

> 00

Type of Service

> 02 f8

Total length - 760 bytes (740 bytes of IP payload)

> 36 98

Identification - 0x3698, same as the previous fragment (which is as it should be)

> 00 b9

Flags and Fragment Offset: fragment offset = 185=185*8 bytes=1480 bytes (which is as it should be, as that's the length of the previous fragment's payload)

> 7f

Time to Live

> 11

Protocol - 17=UDP

> c9 71

Header Checksum

> 62 94 7a 5c

Source Address - same as the previous fragment (which is as it should be)

> ab a1 af a0

Destination Address - same as the previous fragment (which is as it should be)

There isn't anything obvious that should cause Wireshark not to attempt reassembly, but I didn't check the IP header checksum - is Wireshark reporting IP checksum errors on any of the WAN packets?

Can you save just the two offending fragments from the WAN capture to a file?  If so, when you read the file in, does it reassemble the fragments?  If not, could you send us that capture, along with the version information from Wireshark?

> Is there a way to grab the interpreted version of these.

Not with copy/paste, unfortunately.  You could use File->Export to export the dissected version of the packets as text.