Ethereal-users: Re: [Ethereal-users] Illegal fragments

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: Guy Harris <guy@xxxxxxxxxxxx>
Date: Mon, 14 Apr 2003 11:18:54 -0700
On Mon, Apr 14, 2003 at 04:15:26PM +0100, Greg O'Rawe wrote:
> I am getting the error message ``Illegal fragments'' when viewing a snoop of
> traffic between my WAP server and client.
> 
> The server is using WTP SAR to segment the reply, and all seems fine until
> the last packet is reached (WTP TTR flag 1). At this point the ``Illegal
> fragments'' message is report against the last segmented packet, and looking
> at the ``WTP Fragments'' link under the WTP section it reports error
> ``Conflicting data in fragment overlap: True'' for the last packet, and then
> this message plus ``Fragment overlap: True'' when the server attempts to
> retransmit the final packet.
> 
> I can't see anything about this error anywhere, and it appears that the data
> in some bytes of the payload is overlapping. However I can't see why this is
> the case, looking at the header bytes of each WTP segment, and since I know
> that the server is generally reliable in this area.

It's reliable, but, I guess, the client isn't - you said "when the
server attempts to retransmit the final packet", so presumably it thinks
the client didn't receive the final packet.

Ethereal doesn't, in general, handle retransmissions as well as it
should - it treats them the same as regular packets.  This can cause
dissectors to get confused; in this particular case, it didn't just
treat the retransmitted last segmente as a retransmission, it treated it
as a regular part of the segmented packet, and, if it were a regular
part of the packet rather than a retransmission, it *would* represent a
fragment overlap, as the two packets would look as if they were
transmitting the same data (which they *are* doing, given that the
second is a retransmission).

The "Conflicting data in fragment overlap" is a bit odd, though, as that
implies that the data in the retransmission isn't the same as the data
in the original transmission.  Check whether that's the case; if so,
perhaps the server isn't completely reliable, and the data got
retransmitted because the first transmission was in error and was
discarded or NAKed by the client, causing a retransmission.