[Bert Driehuis <bert_driehuis@xxxxxxxxxxxxxxxx>]

Guy Harris wrote:

> > The V.120 trace Bert sent out a while ago has what appears to be 16-bit
> > control fields - and, in fact, the first V.120 frame in that trace is an
> > SABME.  That frame is, of course, a U frame, which means the control
> > field is only one octet - and would be treated as only one octet by
> > "dissect_xdlc_control()" regardless of whether "is_extended" is true or
> > not, so perhaps the V.120 dissector needn't check whether "v120len" is
> > 3, and can just pass TRUE as the "is_extended" argument to
> > "dissect_xdlc_control()".

I plead total ignorance w.r.t. the details of the protocol... I just
laid my hands on the Q.922 spec last week. The only reason I wrote the
decoder was to find out what was involved in actually implementing V.120
for ISDN4BSD. Oh, and the docs suck. Through trial and error I found out
about the modulo 128 thing, for example.

> I've attached a patch to "packet-v120.c" that:
> 
>         makes the "v120.control" field an FT_UINT16 field;

>         always passes TRUE as the "is_extended" argument to
>         "dissect_xdlc_control()";

One of my unanswered questions when I started out, answered only by
implementing V.120 and doing testing... :-)

>         dissects the terminal adaptation sublayer header field after
>         dissecting the control field, so that the V.120 tree shows the
>         data in sequential order;

>         calculates the length of the V.120 header based on the control
>         field type (using the "XDLC_CONTROL_LEN()" macro) and the length
>         of the terminal adaptation sublayer header
>         ("dissect_v120_header()" now returns the length of what it
>         dissects);
> 
>         calls "dissect_data()" on the payload.

Looks excellent... Thanks!

Cheers,

				-- Bert

-- 
Bert Driehuis, MIS -- bert_driehuis@xxxxxxxxxxxxxxxx -- +31-20-3116119
Hi! I'm a signature virus! Copy me to your .signature and help me
spread!