Hmmm.
That might not be as easy as it looks.
I assume the very simple solution to disable TCP Analysis in
preferences is not what
you are looking for :-(
This is a tricky problem since we have to only rely on a single
sequential parsing of the
packet list (since tethereal requires this).
What one could do is to make ethereal re-assigne the base sequence and
base ack numbers when it detects this condition during any of the
first x packets for a tcp session.
That would be a very kludgy solution:-( which would make ethereal
dissect packets differently from tethereal.
Alternatively one could ignore and not test for out-of-order,
prev-segm-lost, retransmission etc during the first x packets?
That would also be quite crappy.
Or one could combine any of the two alternatives above with ONLY doing
it if we started capturing in the middle of the session, i.e. we
didnt see the SYN packet.
Which again would be a suboptimal solution.
Hmmm. I need to think about how to do this in a good way.
Would it be sufficient if i just add a page to the wiki that observes
and expands on that currently, during the first packets of a tcp
session, that the detection of previous-segment-lost, acked missing
segment, and retransmission are unreliable and
will often give unreliable results if the very first packets seen by
ethereal are indeed out-of-order segments?
On Sun, 27 Feb 2005 20:59:58 +0200, Yaniv Kaul <ykaul@xxxxxxxxxxxx> wrote:
> I suspect Ethereal does not support such a case:
> Client: packet 1 (bytes 1407-1661)
> Server: SACK (bytes 1407-1661)
> Client packet 2 (bytes 1 - 1406)
>
> Any ideas how can we add this?
> There's also the work of partially overlapping segments, etc...
>
> A needed short term 'solution', btw, is to change the 'TCP Previous
> segment lost' message, to indicate it might be something else.
>
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-dev
>
