On Tue, 12 Sep 2006 14:50:27 -0700
Guy Harris <guy@xxxxxxxxxxxx> wrote:
> On Sep 12, 2006, at 12:51 PM, Tomasz Noiński wrote:
>
> > Comments about "new_dissector_t" in packet.h say:
> >
> > /*
> > * Dissector that returns:
> > *
> > * The amount of data in the protocol's PDU, if it was able to
> > * dissect all the data;
> > *
> > * 0, if the tvbuff doesn't contain a PDU for that protocol;
> > *
> > * The negative of the amount of additional data needed, if
> > * we need more data (e.g., from subsequent TCP segments) to
> > * dissect the entire PDU.
> > */
>
> The first two clauses (after "Dissector that returns") of that comment
> are true (and there are places where the return value is used as a
> length, e.g. the GSSAPI dissector).
>
> The third clause is false. The intent was to do that at some point,
> but it never happened. (It's probably the wrong thing to do - lengths
> should be unsigned, not signed.)
If it's not true then README.developer should also be changed (not
only the example, but the comments also):
"If there were insufficient bytes in the tvbuff to complete a PDU then
the dissect_PROTO returns a negative value requesting additional bytes."
> > pinfo->desegment_offset = offset;
> > pinfo->desegment_len = 1;
> > return -1;
>
> Try
>
> pinfo->desegment_len = tvb_length_remaining(tvb, offset) + 1;
> return tvb_length(tvb);
I tried it... I'm afraid results were exactly the same.
> instead, or try making it not a "new-style" dissector (so it returns
> nothing) but still change the "pinfo->desegment_len" line in that
> fashion. Let us know whether that works. (I.e., I think the
> desegment_len might be releative to the desegment_offset.)
Also tried it (using old-style dissector). Also, didn't work.
The modified source is at:
http://sphere.pl/~noix/wireshark/2/packet-noix.c
(so you can see yourself if I understood you correctly, if you want)
For the record, I'm testing it with the following TCP packets:
packet 1: "\001\001\000"
packet 2: "\002\002\000\003\003\000"
packet 3: "\004"
packet 4: "\004\000"
packet 5: "\005\005\000\006"
packet 6: "\006\000"
packet 7: "\007"
packet 8: "\007\007\000"
Everything is ok with packets 1-6, but packets 7 and 8 only appear as
"TCP segment of a reassembled PDU", without "C String" in the info
column and without hf_cstring item in the tree.
Noix