[Pascal Quantin <pascal.quantin@xxxxxxxxx>]

2017-07-05 8:32 GMT+02:00 hhw hhw <hhw.hhw7@xxxxxxxxx>:

my packets are like:

                   sequence id    sequence number  message type  

                           16                       0                0 Begin              

                           16                       1                1 Continue               

                           16                       2                2 End (more_frag=FALSE)

PDUs  with sequence number =0-2 should be reassembled here.

PDUs with sequence number =3 -10 : Dont Fragmented

----------------------------------------------------------------------             

                             5                       11               0 Begin               

                             5                       12               1 Continue         

                             5                       13               2 End  (more_frag=FALSE) 

PDUs  with sequence number =11-13 should be reassembled here.

PDUs with sequence number =13 -19 : Dont Fragmented

-----------------------------------------------------------------------   

                             16                      20               0 Begin                       

                             16                      21               2 End (more_frag=FALSE)

PDUs  with sequence number =20-21 should be reassembled here.   

Now. How can i reassemble fragmented PDUs? which reassembly function? 

fragment_add_seq_check or fragment_add_seq or fragment_add_check ?

It's a shame your protocol does not have an explicit fragment number. I wonder how this is supposed to work if you have a UDP datagram loss... If this can be changed, better do it and it would solve your reassembly API usage headache at the same time.

Anyway, please reread carefully all the emails I sent you:

- either you use fragment_add_seq_check and in that case you must put some intelligence in your code to know what was the last sequence number of the last message, so as to ensure that you call this function with frag_number starting from 0 for each new message,

- or if you are really sure that no packet loss can happen and that reorder delivery is ensured, you can probably use fragment_add_seq with the REASSEMBLE_FLAGS_NO_FRAG_NUMBER flag (I even gave you the code in my first email)

So please take the time to think carefully about what I told you and experiment. There is hardly more we can do for you.

Pascal.

PS: please locate the "reply all" button of your email cleiant so as to stop dropping wireshark-dev list. I'm putting it on purpose so that you can get help from other developers, and so that your questions can help any other developer interested by reassembly API.

On Wed, Jul 5, 2017 at 10:42 AM, hhw hhw <hhw.hhw7@xxxxxxxxx> wrote:

excuse me, ok,  i want to follow your explanation.
how can i use  fragment_add_check in my dissector?
In your first reply you told me how to use fragment_add_check or
fragment_add_seq?

On 7/5/17, Pascal Quantin <pascal.quantin@xxxxxxxxx> wrote:
> Le 5 juil. 2017 07:16, "hhw hhw" <hhw.hhw7@xxxxxxxxx> a écrit :
>
> according to answer of this question ( https://ask.wireshark.org/ques
> tions/61818/how-to-reassemble-fragments-in-a-dissector-by-
> fragment_add_seq_check-function ), I need to use fragment_add_check(), but
> if
> i use fragment_add_check function packets 1,2,3 reassembled incorrectly and
> hf_msg_fragment_overlap fields is true, and packets 4,5,6 aren't
> reassembled.
>
>
> It's up to you: either you follow my explanation of why your reassembly
> fails and you modify your code accordingly (and it will work) or you
> continue not listening to advices.
> In my first reply I told you how to use fragment_add_check (I got it
> working with the sample you posted on ask site) and why you should probably
> avoid it.
>
>
> On Wed, Jul 5, 2017 at 9:39 AM, hhw hhw <hhw.hhw7@xxxxxxxxx> wrote:
>
>> i stopped using morefrag because i want to show start and end of a
>> reassembling process.   and my messages always dont have up to 3
>> fragments.
>>
>> On Wed, Jul 5, 2017 at 9:36 AM, Pascal Quantin <pascal.quantin@xxxxxxxxx>
>> wrote:
>>
>>> [once more, please keep wireshark-bugs mailing list in copy, thanks]
>>>
>>>
>>> Le 5 juil. 2017 06:41, "hhw hhw" <hhw.hhw7@xxxxxxxxx> a écrit :
>>>
>>> hi pascal. thank you very very... much.
>>> i shall change my dissector code. Now, my packets are like :
>>> packet nb  sequence id    sequence number  message type
>>> 1          16             0                0 Begin
>>> 2          16             1                1 Continue
>>> 3          16             2                2 End (more_frag=FALSE)
>>> ----------------------------------------------------------------------
>>>
>>> 4          5              11               0 Begin
>>> 5          5              12               1 Continue
>>> 6          5              13               2 End  (more_frag=FALSE)
>>> -----------------------------------------------------------------------
>>>
>>> 7          16             20               0 Begin
>>> 8          16             21               1 Continue
>>> 9          16             22               2 End (more_frag=FALSE)
>>>
>>> i use messagetype instead of morefrag. When messagetype=2 it means
>>> more_frag=FALSE and  this should complete reassembly.but i have problem,
>>> and packets 4,5,6 and packets 7,8,9  aren't reassembled.
>>> my fragment may start at any sequence number (zero or non zero) . if an
>>> END message has been received a sequence id can assaign to another
>>> groups
>>> of packets( like id =16) .can you HELP me?
>>>
>>>
>>> As I already explained in my previous message, the reassembly API
>>> expects
>>> the frag_number parameter to start from 0 for the first fragment of a
>>> given
>>> message and increase by 1 for each new fragment of the same message. If
>>> you
>>> apply this rule it will just work.
>>> I don't know why you stopped using morefrag (which was perfectly fine)
>>> but if your messages always have up to 3 fragments you could use the
>>> message type as frag_number. If you can have several Continue packets
>>> for
>>> the same message, then you need to find another way to provide the
>>> frag_number parameter.
>>>
>>> Best regards,
>>> Pascal.
>>>
>>
>>
>