The first fragment was complete - 1500 bytes. The remaining fragments
appeared to be missing from the trace.
A related problem is that vms.c fails to parse all but the first
fragment of a packet. This is because subsequent fragments are not
tagged at TCPtrace packets, and have no timestamp.
In my private version I now accept packets that are not tagged
TCPtrace. I also contacted the maintainer of TCPtrace as to this
issue. I am hesitant to release the modified code because it may parse
lines of text after the end of the dump, and perhaps behave strangely.
I will wait to hear what the TCPtrace maintainer says after he returns
from his leave.
When ethereal reads all the fragments, it does decode them.
-Marc
On Thu, 2002-03-07 at 15:36, Guy Harris wrote:
> On Thu, Mar 07, 2002 at 03:12:34PM -0500, Marc Milgram wrote:
> > I turned on IP->Reassemble fragmented IP datagrams, then loaded a dump.
> >
> > Ethereal read the first fragment of a fragmented packet, but not the
> > subsequent fragments. Ethereal failed to decode the packet past the IP
> > level (it recognized that it was a UDP packet, but did not decode the
> > UDP, RPC, or NFSV3 protocol layers).
> >
> > If I turn off Reassemble fragmented IP datagrams, it will decode the
> > fragment correctly.
>
> Are all the fragments present? If not, it won't reassemble.
>
> Are all the fragments complete, or is the capture length shorter than
> the actual length for any of them? If not, it won't reassemble.
>
> Are the IP checksums valid on all the fragments? If not, it won't
> reassemble.
>
> It definitely *does* reassemble IP fragments on some captures, so it's
> not as if the feature isn't working at all; there's definitely
> *something* different about your capture.
>
> Note also that the reassembled packet is dissected on the
> (chronologically) *last* fragment, not the *first* fragment - the packet
> summary will show all but the last fragment as just IP fragments.