I'm still having issues with TCP reassembly when PDU's are split across TCP
segments. This is a local build of r22258.
The attached capture shows the problem in frame 5 which has the end of the
first DNP 3 PDU in bytes 0-67 and the start of the next PDU in bytes 68-89.
For the second PDU, the DNP dissector function (dissect_dnp3_tcp) is correctly
called with a tvb of 22 bytes, which calls tcp-dissect_pdus, which then calls
get_dnp3_message_len which correctly returns the PDU length of 292.
This is shown in the tcp part of the tree for frame 5 as a PDU size of 292 and
TCP segment data of 68 bytes for the first PDU that ended in the segment, and
a PDU size of 292 and a TCP segment data of 22 bytes for the next PDU that
started in the segment.
However, when dissect_dnp3_tcp is next called, the tvb has 231 bytes, and is
in fact the next tcp segment data from frame 7. The data from the previous
segment has been discarded and now the dnp3 dissector returns 0 as the PDU
header bytes don't match that required by the protocol.
I've attempted to work though the tcp reassembly code to find out where the
first part of the PDU has been lost, but admit defeat as I'm not up to this.
Is anyone looking at this at all?
--
Regards,
Graham Bloice
Attachment:
badclass0.cap
Description: Binary data