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".