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.