OK, after taking a look at the TCP dissector, I noticed that TCP didn't allow reassembly on my trace because the packets had incorrect TCP checksum.
Disabling the "Check the validity of TCP checksum" option from the TCP preferences did the magic and now everything is decoded fine. Bogdana Bogdana Botez wrote: > Hello, > > I'm writing a plugin for a protocol PROTO running on TCP. The packet > reassembly (done with tcp_dissect_pdus) works fine, with one exception. > Sometimes, more PROTO packets come on the network concatenated in one > TCP packet - and as they get concatenated the packet gets too large and > it's split, something like this: > > packet 1: > ---------- > Linux cooked header > IP header > TCP header > PROTO header+body #1 (complete) > PROTO header+body #2 (complete) > .. > PROTO header+body #k (incomplete) > > > > packet 2: > ---------- > Linux cooked header > IP header > TCP header > PROTO header+body #k (continued from the previous packet) > PROTO header+body #k+1 (complete) > .. > PROTO header+body #n (complete) > > > In this case the first packet is dissected OK, with the exception of > PROTO header k ([Unreassembled Packet]). But the second packet gets all > messed-up, because the plugin doesn't know anymore that the second > packet is the continuation of the first packet (even if I used > tcp_dissect_pdus for the reassembly). > > In all the other cases (only TCP concatenation without fragmentation - > or fragmentation without TCP concatenation) the plugin works fine. > > How could I solve this problem? > > Thanks > Bogdana > > > _______________________________________________ > Wireshark-dev mailing list > [email protected] > http://www.wireshark.org/mailman/listinfo/wireshark-dev > _______________________________________________ Wireshark-dev mailing list [email protected] http://www.wireshark.org/mailman/listinfo/wireshark-dev
