On 4 mei 2011, at 22:48, Jeff Morriss wrote: > Sake Blok wrote: >> On 4 mei 2011, at 22:11, Jeff Morriss wrote: >>> Max Dmitrichenko wrote: >>>> Hi! >>>> I'm continue to write dissector for an encrypted protocol. Everything >>>> works fine until I receive an out-of-order TCP segment, i.e. previous >>>> was lost. >>>> Since I'm trying to decrypt it, I fail with it and break the whole >>>> decryption context. Is there any way to: >>>> 1) Detect that this packet is out of order in given conversation? >>>> 2) Ask the TCP dissector to feed this packet later again when all >>>> previous segments will be retransmitted? >>> I would think desegment_tcp() should be able to handle this by not calling >>> your dissector for an out-of-order segment: it should be able to only call >>> your dissector once it has a completely reassembled (desegmented) PDU. >>> Looking through the code, it's not immediately obvious to me what the >>> problem is. >> One case that can cause a problem is when the first segment of a PDU is >> received out-of-order. Or did your recent work also handle this exception, >> Jeff? > > Yep, that's the case rev 36304 fixed.
Unfortunately not, I just constructed a file in which the first segment of the HTTP-response PDU comes after the second segment of that PDU. And dissection still fails as there is not yet a segment in tcpd->fwd->multisegment_pdus for that seq. This could be fixed by adding a segment that comes after a gap to the multisegment list by default, but that would break dissection of single segment PDU's that come out-of-order. I don't know of a good way to solve this dilemma. Cheers, Sake ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
