2011/5/5 Jeff Morriss <jeff.morriss.ws@xxxxxxxxx>:
> Sake Blok wrote:
>>
>> On 4 mei 2011, at 22:11, Jeff Morriss wrote:
>>
>>>
>>> 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.
Sake and Jeff, thank you for your replies. Indeed the problem is when the first
segment of multisegment PDU is received out-of-order, i.e. later than the second
segment, for example. Provided that protocol is encrypted (including framing
headers), I'm not able to deduct anything at the beginning of
dissection. I try to
decrypt this fragment, but decryption fails and more over the decryption context
is spoiled after this try - all later packets are decrypted into the junk.
If the first segment of PDU is received in order then all other
segments seems to be
assembled correctly despite of their order - I have observed such situations.
Let's get back to your statement, Jeff. Suppose, we have PDU of 3
fragments which
come in this order: 2, 1, 2 (dup), 3. What should I write in the
dissector to handle
this correctly? Or may be you can point me to the code of any existing dissector
which handles this?
--
Max