The current tcp reassembly functions are pretty old and require
in-order segments.
the framework for tcp reassembly was developed before the tcp analysis
framework was developed and can thus not use the implementation of
sliding windows that now exists inside ethereal.
i think the best long term solution would be to refactor the tcp
reassembly routines completely to piggy back on the tcp analysis
engine and thus be able to handle out-of-order segments properly.
another enhancement the tcp reassembly would benefit from would be to
be able to reassemble a PDU of unknown length, a PDU that continues
all the way until the RST or FIN segment is seen.
In particular this would make ethereal be able to handle several
protocols/implementation that are implemented ontop of HTTP and where
there is no content-length specified in the HTTP header. There are
quite possibly other protocols running atop tcp that could use this as
well, i know at least of 3 different implementations/protocols atop
HTTP where this would help.
both these fixes would be longer term goals in my opinion, i can
not promise when i will be able to implement such a change, i will
not have time in the near future however :-(
On Mon, 3 Jan 2005 17:43:03 +0200, Sergey Makarenko
<SMakarenko@xxxxxxxxxxxxxx> wrote:
>
> Hello,
>
> I make a dissector for a protocol which works atop TCP and I want to use
> reassembly functionality provided by tcp dissector.
> All works fine until lost packet situation occurs.
> Since this protocol uses encryption it is necessary to revceive data in
> correct order.
> When I receive a some packet (let's name it packet_A) and I decide to do
> reassembly then I return execution to the tcp dissector and wait for more
> data.
> Let's suppose that the next packet in the tcp stream (packet_B) was lost.
> Then the next packet that my dissector will receive will be packet_C (which
> follows packet_B in the tcp stream).
> And only when tcp dissector will met retransmitted packet_B it will join
> packet_A and packet_B and pass this data to my subdissector.
> Hence the reassembly functionality of the tcp dissector doesn't keep the
> continuity of the tcp stream.
> I don't see the way how subdissector can recognize lost packet situation.
> Also subdissector doesn't have access to SEQ/ACK numbers of the tcp stream.
> So it can not reorder packets by itself.
> As I can see other dissectors also use this technique and rely only on the
> tcp dissector functionality.
>
> So, is there any way to deal correctly with lost packets/retransmission for
> subdissector and receive data in correct order?
>
> Best regards,
> Sergey Makarenko.
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-dev
>
>
>
