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. _______________________________________________ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
