Given a two packet sequence, with one pdu occupying the whole first packet plus part of the second, followed by another pdu in the second packet:
On first first call to get_pdu_len(), a greater number than tvb_length() is returned. The tcp dissector goes away and waits for more data. Eventually get_pdu_len() is called again with a buffer containing precisely the requested number of bytes and returns the same number. tcpinfo.seq contains the sequence number of the start of the first packet (the sequence number of the first byte of the current pdu). The buffer is passed to the dissector and all is well so far. Then get_pdu_len() is called again with a buffer containing just the remainder of the second packet, and an offset of 0. tcpinfo.seq is still equal to the sequence number of the first packet/pdu. I can't see any way of getting the sequence number of the first byte of the *current* pdu, nor of getting the number of bytes of reassembled data that have already been processed in the current reassembly run (from which I could work out the seq number). Surely there must be a way? John -- Dead stars still burn _______________________________________________ Wireshark-dev mailing list [email protected] https://wireshark.org/mailman/listinfo/wireshark-dev
