Two things are missing:
* it loooks at ACKs in the other direction which advances the left edge of
the tcp analysis window
and thus it will miss pdus starting in the middle of lingering tcp segments
that are delayed. This would be trivial to add,
just change it to only forget pdu starts htat are more than x (==50) kb
prior to the window left edge.
* it does not handle sequence number wrapping which may occur if relative
sequence numbers are not enbaled.
----- Original Message -----
From: "Ronnie Sahlberg"
Sent: Wednesday, April 23, 2003 9:23 PM
Subject: [Ethereal-dev] New TCP feature : pdu tracking
> I just checked in a new feature to TCP which allows dissectors to provide
> hints
> to TCP (and maybe in the future SMB-PIPE) of where the next protocol PDU
> starts.
>
> This allows TCP to find and call the proper dissector for PDUs even if
they
> start in the middle of a segment.
>
> I.e. it allows TCP to find out that a ONC-RPC/NFS starts in the middle of
a
> segment and allows it to call the
> ONC-RPC dissector properly inastead of just markign it as RCP
continuation.
> This happens a lot for Linux kernel TCP NFS hosts with a slow link since
> apparently Linux now often will, on a saturated outgoing queue, collapse
the
> final non-fullsize PSH segment into a normal full-size segment containing
> both the tail of the previous PDU as well as the head of the next PDU even
> before it gets out on the wire. i.e. initial transmit of the segment, not
> just for retransmissions.
> I do not know of other OSs that will collapse non-full PSH segments
sitting
> in the outgoing queue.
>
>
> This feature piggybacks on the tcp analysis code
> (which had a bugfix for base_[seq|ack] handling i hope has no sideeffects)
> and will be enabled by enabling the tcp analysis feature.
> Note that this feature is implicitely disabled if TCP desegmentation is
> enabled since i did not complete
> determining how they may interact (badly).
>
> Currently only ONC-RPC (==NFS) over TCP use this feature but it should be
> trivial to add it to the other TCP based protocols. Please see todays
> change to packet-rpc.c as a trivial example.
>
> I think we should at least have NBSS which together with ONC-RPC would
make
> up most of the
> (for some people) interesting protocols. Volunteers?
>
>
> I have tested it successfully with ONC-RPC/NFS captures and no TCP
> desegmentation enabled. It seemed to work ok.
> Please test for regressions for TCP analysis if you happen to use that
> feature.
>
>
> best regards
> ronnie s.
>
>
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-dev
