Richard Sharpe wrote:
>
> At 07:53 AM 11/30/00 -0600, you wrote:
> >Hi,
> >
> >
> >Just to keep people informed on the task I have undertaken,
> >to generate ethereal dissectors from IDL descriptions,
> >here is my current battleplan. Thanks to those people
> >with whom I have spoken with so far.
> >
> >This should be very useful for the CORBA stuff appearing these days.
> >
> >1. Generate packet-idl-xxx.[ch] from IDL doc's.
> > I am writing a backend to the omniidl compiler that
>
> Hmmm, what type of beast is this compiler? Where can I find out more?
>
see
http://www.uk.research.att.com/omniORB/
> >6. The called IDL dissector can decode as usual, but
> > can use the CDR routines in giop to decode the
> > CDR types , and automatically handle alignment
> > within the octet stream.
> >
> > eg: IDL based dissectors
> >
> >octet1 = get_CDR_short(tvb, offset)
> >proto_tree_add_int(idlxxx_tree, hf_idlxxx_yyy,tvb, offset,1,octet1);
>
> Hmmm, the stuff below can be written as
>
> proto_tree_add_item(btap_tree, hf_btap_msgtype, tvb, offset, 1, FALSE);
>
of course!! it is just an example :-)
> with the hf_btap_msgtype entry specifying all the required info ... Can we
> not extent proto_tree_add_item to understand the various types you are adding?
>
Yep, and if we are happy to expand the tvb_xxx stuff to handle IDL types
and CDR alignment, then my life is a lot easier!!
Then my backend just writes plain vanilla dissectors with the
new tvb_xxx stuff, and the get_CDR_xxx could be bypassed.
Comments ??
Cheers / Frank..
--
EUS/SV/Z Frank Singleton ASO Americas BSS
Office : +1 972 583 3251 ECN 800 33251
Pager : +1 800 651 1184 Email : eusfrsi@xxxxxxxxxxxxxxx
Amateur Radio: VK3FCS/KM5WS Email : frank.singleton@xxxxxxxxxxxx
Hardware: HP Omnibook 4150 running Redhat Linux 6.2 (2.2.16 kernel).