> Currently I am instead receiving too much data in the reassembled
> packets. But I guess that is a problem with my code. I will try and hunt
> it down myself...
Do you mean the fact that ethereal will append all the bytes from the
tail segment to the reassembly and not just enough data to satisfy
desegment_len?
If so, that behaviour is by design.
The reason is that in the same way as a pdu might span multiple
segment, a segment might also contain multiple pdu's.
So, when the data has been reassembled, there might be another PDU
starting in the trailing data in the tail of the last segment appended
to the reassembly buffer.
Your code must check for this.
When the code has finished dissecting the current PDU it MUST check if
there are more bytes remaining in the tvb and if so, start dissecting
the next PDU.
(
All this is so much easier if your protocol allows you to use tcp_dissect_pdus()
)
On Wed, 01 Sep 2004 14:53:14 +0200, Peter Johansson
<peter.xc.johansson@xxxxxxxxxxxx> wrote:
> Jeff Foster wrote:
>
> >This will work for a fixed length PDU, which does seem to be Peter's
> >situation, or a PDU with a length value in the start of the PDU.
> >
> This is exactly my situation.
>
> ---8<--- snip snip ---8<---
>
> >>From: Ronnie Sahlberg
> >>Sent: Wednesday, September 01, 2004 4:14 AM
> >>
> ---8<--- snip snip ---8<---
>
> >>remember to enable BOTH the tcp preference as well as your own
> >>preference for your protocol to enable desegmentation.
> >>
> Yes, thank you. I tracked this down myself a few hours ago (reading the
> source code). Enabling "Allow subdissector to reassemble TCP streams" in
> the preferences for TCP made my life a whole lot easier. I would really
> have liked to see something about this in the README.developer. It would
> sure help others in the future.
> I would like to see additional notes in the README.developer, section
> 2.7, showing the use of "pinfo->can_desegment". It seems rather vital
> after having read through a bunch of other dissector sources.
>
> Currently I am instead receiving too much data in the reassembled
> packets. But I guess that is a problem with my code. I will try and hunt
> it down myself...
>
> Thanks for your replies!
>
> / Peter
>
>
