Thanks, now I understand. I was looking at the packet list, and not at the
decode tree and so was thinking that the fact that I was still seeing
"Fragmented IP protocol" packets meant that the reassembly wasn't happening.
Is there any way to prevent the fragments from being displayed after
reassembly has occurred? What I really want to do is look at the trace
without knowing that the packets were fragmented on the wire.
Thanks,
Chris.
----- Original Message -----
From: "Guy Harris" <gharris@xxxxxxxxx>
To: "Chris Waters" <chris@xxxxxxxxxxxx>
Cc: "EtherealUsers" <ethereal-users@xxxxxxxxxxxx>
Sent: Saturday, June 08, 2002 3:29 AM
Subject: Re: [Ethereal-users] IP Fragment Reassembly
> On Fri, Jun 07, 2002 at 10:57:26PM -0700, Chris Waters wrote:
> > What is the expected operation of the IP fragment reassembly option?
>
> It's expected to reassemble fragmented IP datagrams. :-)
>
> All but the last fragment should say "IP" in the Protocol column and
>
> Fragmented IP protocol (proto={the protocol}, off={the offset})
>
> in the Info column, and the last fragment ("last" as in "the one that
> was captured last") should show the appropriate protocol in the Protocol
> column and the appropriate stuff in the Info column. Under the
> "Internet Protocol" tree item in the protocol tree pane there should be
> an "IP Fragments" subtree, with information about the frames containing
> the fragments.
>
> > I enabled the option and captured a series of 2000 byte pings but didn't
> > notice any difference. i.e. the packets weren't reassembled in the
> > display.
>
> I have it enabled by default, and just did some 2000-byte pings, and it
> reassembled them.
>
> > I also tried saving and reopening the trace, but that didn't
> > change anything either. Is it working correctly? I am using a version
> > built from the latest sources.
>
> I'm also using a reversion built from the latest CVS source.
>
> Note that if
>
> 1) you didn't capture the full packet (i.e., you gave a snapshot
> length not large enough to get all the packet data)
>
> or
>
> 2) the IP checksum isn't valid
>
> reassembly isn't done.
>