John R. wrote:
I have an issue with desegmentation of packets: if the minimal header
required to judge length is broken across TCP segments A and B, at
segment A it decides properly to return expecting the remainder of the
minimal header. In my problem case, the next tcp segment to arrive has
the remainder of this packet and several others. It calls my pdu
measurement routine which through printf's I've determined is properly
returning the length of the full PDU.
That length includes the minimal header, right? I.e., a 30-byte PDU
would have a 5-byte minimal header plus 25 bytes of payload after the
minimal header; in that case, your routine should be returning 30, not
25, even if the length is determined by a value in the minimal header,
and that value is the length of data *after* the minimal header (i.e.,
25, in the example I gave).
Once segment B appears should tcp_dissect_pdus stay in the dissect
loop until all packets within it are decoded?
Yes (if by "within it" you mean "fully within it or previous TCP
segments"; the last packet might have the start, but not the end, in
that segment, in which case it can't dissect the last packet at that point).
Are TCP segments A and B in order in the capture?
What function calls my outer dissector that calls tcp_dissect_pdus?
decode_tcp_ports(), in epan/dissectors/packet-tcp.c.
It's called from process_tcp_payload(), also in
epan/dissectors/packet-tcp.c, and that's called by desegment_tcp() and
dissect_tcp_payload(), also in epan/dissectors/packet-tcp.c.
dissect_tcp_payload() is called from dissect_tcp(), and it calls
desegment_tcp() if it can do desegmentation.