Differences between revisions 5 and 6
Revision 5 as of 2006-06-05 03:19:17
Size: 3130
Editor: localhost
Comment:
Revision 6 as of 2008-04-12 17:51:24
Size: 3138
Editor: localhost
Comment: converted to 1.6 markup
Deletions are marked like this. Additions are marked like this.
Line 5: Line 5:
fragmented ["IP"] Datagrams into a full ["IP"] packet before calling the higher layer dissector. fragmented [[IP]] Datagrams into a full [[IP]] packet before calling the higher layer dissector.
Line 10: Line 10:
attachment:ipreassembly.jpg {{attachment:ipreassembly.jpg}}
Line 14: Line 14:
First of all, Wireshark will no longer dissect the ["UDP"] or ["TCP"] header (or any protocol above these) in the frame that contained the header of the ["IP"] packet any more. Instead, the calling of the ["UDP"] or ["TCP"] protocol dissectors will be deferred until all ["IP"] fragments have been received and the full ["IP"] datagram has been fully reassembled. First of all, Wireshark will no longer dissect the [[UDP]] or [[TCP]] header (or any protocol above these) in the frame that contained the header of the [[IP]] packet any more. Instead, the calling of the [[UDP]] or [[TCP]] protocol dissectors will be deferred until all [[IP]] fragments have been received and the full [[IP]] datagram has been fully reassembled.
Line 16: Line 16:
This difference shows up as that without IP Reassembly the upper layer protocol, ["UDP"] or ["TCP"] and whatever sits above it, as much as was present in this frame of the initial fragment (where fragment offset is 0) will be dissected and displayed for that particular frame. This frame will also usually have an information text in the packet summary line along the lines of "[Short Frame]". All the other ["IP Fragment"]s for this ["IP"] datagram will be dissected only up to and including the ["IP"] layer. This difference shows up as that without IP Reassembly the upper layer protocol, [[UDP]] or [[TCP]] and whatever sits above it, as much as was present in this frame of the initial fragment (where fragment offset is 0) will be dissected and displayed for that particular frame. This frame will also usually have an information text in the packet summary line along the lines of "[Short Frame]". All the other [[IP Fragment]]s for this [[IP]] datagram will be dissected only up to and including the [[IP]] layer.
Line 18: Line 18:
When this feature is enabled, dissection of the ["IP"] datagram will be deferred until that packet in the capture where the full ["IP"] datagram was completely reassembled. When this feature is enabled, dissection of the [[IP]] datagram will be deferred until that packet in the capture where the full [[IP]] datagram was completely reassembled.
Line 20: Line 20:
This means that some packets that are using reassembly, such as ["NFS"]over["UDP"], will dissect differently, and even in different frames when IP Reassembly is enabled. This means that some packets that are using reassembly, such as [[NFS]]over[[UDP]], will dissect differently, and even in different frames when IP Reassembly is enabled.
Line 23: Line 23:
IP Reassembly is an all-or-nothing feature. If not every single ["IP Fragment"] required to complete the reassembly can be found in the capture, then nothing at all will be dissected. Not even the ["TCP"] or ["UDP"] layer. IP Reassembly is an all-or-nothing feature. If not every single [[IP Fragment]] required to complete the reassembly can be found in the capture, then nothing at all will be dissected. Not even the [[TCP]] or [[UDP]] layer.
Line 27: Line 27:
 * Short packets. You have captured packets with a SnapLen less than the ["MTU"] of the link and thus some of the packet(s) content are missing, then Wireshark will not even try to perform reassembly.  * Short packets. You have captured packets with a SnapLen less than the [[MTU]] of the link and thus some of the packet(s) content are missing, then Wireshark will not even try to perform reassembly.
Line 29: Line 29:
 * Some of the ["IP Fragment"]s are just plain missing from the capture. This is a fact of life, you will never have a guarantee that every single packet that went across the wire was actually captured and written to the Capture File. sorry that is just a fact of life :-(  * Some of the [[IP Fragment]]s are just plain missing from the capture. This is a fact of life, you will never have a guarantee that every single packet that went across the wire was actually captured and written to the Capture File. sorry that is just a fact of life :-(
Line 32: Line 32:
This feature WILL consume a lot of additional memory at runtime if there are ["IP Fragment"]s present in the trace.
It is a very very bad idea to enable this feature for huge ["NFS"]over["UDP"] traces since that will eat memory like there is no tomorrow.
This feature WILL consume a lot of additional memory at runtime if there are [[IP Fragment]]s present in the trace.
It is a very very bad idea to enable this feature for huge [[NFS]]over[[UDP]] traces since that will eat memory like there is no tomorrow.
Line 38: Line 38:
attachment:ipreassembly.jpg {{attachment:ipreassembly.jpg}}

IP Reassembly

IP Reassembly is a feature in Wireshark and TShark to automatically reassemble all fragmented IP Datagrams into a full IP packet before calling the higher layer dissector.

This feature will require a lot of extra memory to be consumed by wireshark in order to store the reassembly buffers and is disabled by default.

To enable IP Reassembly, go to preferences and tick the box for reassembly ipreassembly.jpg

When you enable IP Reassembly several things in TShark and Wireshark change. First of all, Wireshark will no longer dissect the UDP or TCP header (or any protocol above these) in the frame that contained the header of the IP packet any more. Instead, the calling of the UDP or TCP protocol dissectors will be deferred until all IP fragments have been received and the full IP datagram has been fully reassembled.

This difference shows up as that without IP Reassembly the upper layer protocol, UDP or TCP and whatever sits above it, as much as was present in this frame of the initial fragment (where fragment offset is 0) will be dissected and displayed for that particular frame. This frame will also usually have an information text in the packet summary line along the lines of "[Short Frame]". All the other IP Fragments for this IP datagram will be dissected only up to and including the IP layer.

When this feature is enabled, dissection of the IP datagram will be deferred until that packet in the capture where the full IP datagram was completely reassembled.

This means that some packets that are using reassembly, such as NFSoverUDP, will dissect differently, and even in different frames when IP Reassembly is enabled.

IP Reassembly is an all-or-nothing feature. If not every single IP Fragment required to complete the reassembly can be found in the capture, then nothing at all will be dissected. Not even the TCP or UDP layer.

Common reasons why IP Reassembly fails to reassemble packets:

  • Short packets. You have captured packets with a SnapLen less than the MTU of the link and thus some of the packet(s) content are missing, then Wireshark will not even try to perform reassembly.

  • IP Header Checksum is invalid. If the IP Header Checksum is invalid, then the IP Reassembly function will ignore the packet.
  • Some of the IP Fragments are just plain missing from the capture. This is a fact of life, you will never have a guarantee that every single packet that went across the wire was actually captured and written to the Capture File. sorry that is just a fact of life :-(

Beware

This feature WILL consume a lot of additional memory at runtime if there are IP Fragments present in the trace. It is a very very bad idea to enable this feature for huge NFSoverUDP traces since that will eat memory like there is no tomorrow.

Display

To enable IP Reassembly tick this preference setting ipreassembly.jpg

Preference String

Reassemble fragmented IP datagrams.

IP_Reassembly (last edited 2008-04-12 17:51:24 by localhost)