Re: Identification of Fragmented UDP Packets

[Guy Harris <guy () alum mit edu>]

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.
___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request () wireshark org?subject=unsubscribe