Hi Ricardo,
Ok, I can extend the reassembly routines in such a way that general and TCP
reassembly can be used to
say "Ok, thanks for reassembling the PDU, but I just changed my mind, the
new size of this PDU should be
X bytes instead of what I previous said, please continue reassembly".
I cant do this today, but can do it during the weekend.
It should not be too difficult and I think I know how to do it without
obfuscating reassembly.c too much.
If you havent seen any followups from me before sunday/monday, just give me
a shout and I will fix this feature for you.
----- Original Message -----
From: "Guy Harris"
To: "RIcardo Barroetaveña"
Sent: Friday, December 28, 2001 8:38 AM
Subject: Re: [Ethereal-dev] ldp dissector, desegment_tcp()
> On Thu, Dec 27, 2001 at 04:43:57PM -0300, RIcardo Barroetaveña wrote:
> > I'm trying to complete the ldp subdissector. I'm planning to
> > request desegmentation to the tcp dissector. But I have a problem when
> > I don't have the first 4 bytes of the LDP PDU in the tvb (LDP
> > PDU=guint16 version; guint16 PDU Length; etc). I must first request the
> > bytes to fill the header and then make another request for the rest of
> > the PDU.
> >
> > For what I've understood from the code, I think function
> > desegment_tcp() (in packet-tcp.c) is not prepared to handle this case.
>
> The desegmentation code currently isn't explicitly set up to be told by
> a subdissector "I need N more bytes" and, when it's assembled those N
> bytes and handed them to the dissector, to be told "thanks, but I now
> need M more bytes". I.e., it's not prepared to be told "I need at least
> N more bytes but, when I get those N more bytes, I'll probably need
> more, so the PDU probably won't be completely desegmented after those N
> bytes have arrived.
>
> And, yes, you are correct, in order to *completely* handle TCP
> desegmentation, the desegmentation needs to be modified to support that.
> It's *typically* the case that the "header" of a PDU (the part that
> specifies the PDU length) will be entirely in one TCP segment, but it's
> not *guaranteed* to be the case.
>
> > And one option is to make some changes to the function. Do you think
> > it's a feasible one?
>
> Yes, I suspect it is. I haven't looked at it in detail.
>
> > Do you have any suggestions?
>
> One way to do it might be to add to the "packet_info" structure a field
> that a sub-dissector can set to indicate that "desegment_len" isn't the
> amount of data needed to *complete* the PDU, it's the amount needed to
> *find out* how much data is needed to complete the PDU.
>
> Another possibility might be to modify "desegment_tcp()" so that it can
> handle the case where it's found all the bytes that the subdissector
> told it were necessary, but the subdissector tells it "I need more".
> Unfortunately, it currently does handle that case - but it assumes this
> means that the subdissector fully dissected the PDU that was reassembled
> but there was *more* data in the segment *after* that PDU, which was
> part of a *subsequent* PDU.
>
> As such, we'd either need to have some way to distinguish between "I
> need still more data for the first PDU" from "I handled that PDU but
> there's another incomplete PDU", or we need to do something such as
> having the reassembly code reassemble only the data for one PDU, hand
> the subdissector data for that PDU, and then, if there's more data in
> the current segment (the one that finished up that PDU), make *another*
> call to the subdissector for the remaining data.
>
> > I've already seen other dissectors but they don't seem to be handling
> > this case.
>
> That's because there's currently no way for them to tell the TCP
> dissector "I don't even have enough data for the PDU header, so here's
> how many bytes I need for that; that's probably not all the data I'll
> need for this PDU, however".
>
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-dev
