Wireshark · Ethereal-dev: [Ethereal-dev] GIOP + idl2eth

[Frank Singleton <frank.singleton@xxxxxxxxxxxx>]

Hi,

Sorry for the long post but ....

Well I finally get around to releasing some code. Thanks to
Ericsson for allowing me to spend some time working a COOL  Open
Source project, and to allow releasing of my code changes.

So, whats included ?

There are 4 things.

1. packet-giop.[ch] update
2. idl2eth - auto generate ethereal code from IDL
3. logfiles of captured corba traffic, using the IDL's
   included.
4. Copies of autogenerated dissector, so you can try them out.
   However, I urge you to delete them , and generate your own
   automatically (see below).

Firstly, we have added an API on top of GIOP to pull IDL types
using CDR from a GIOP octet stream, and handle  alignment for these
types. 

You can look at packet-giop.h to see the visible functions, but 
I can say that the following  types are handled.

get_CDR_float (ieee 754-1985)
get_CDR_double (ieee 754-1985)
get_CDR_short
get_CDR_long
get_CDR_ushort (unsigned)
get_CDR_ulong
get_CDR_char
get_CDR_boolean
get_CDR_any        ! phew !
get_CDR_octet
get_CDR_enum
get_CDR_string
get_CDR_object    (IOR)
get_CDR_interface (IOR)
get_CDR_typeCode

etc ..

and of course, sequences of such data etc..

Note, get_CDR_wchar and get_CDR_wstring are present
but the API for those are not complete (yet). The decription
of how these are encoded is a little tricky, and some
vendors have chosen to map these types to other types.
eg : I have seen unicode used on "the wire" for wstring
etc..

Also, there is an API to allow for both explicit and heuristic
dissectors to register with GIOP. It can also read stringified
IOR's from file.
The heuristic one is great for when you have NO access to 
mapping between objkeys and Repository Id's.

So, IDL's that dont have duplicate operation names should be handled ok.

IDL's that do implement common operation names (but different namespace)
need some way of obtaining  the correct operation "scope". This is where 
I have begun work on an ObjectKey/RepoId mapping. This is a work in progress.
See packet-giop.c for comments on this. I have however tested this logic
on some simple cases without problem. see SameName example for details.


IOR's are decoded when present.

Also if you put giop into DEBUG mode, then you will get copius 
amounts of data, mainly showing things like ..

- Any objkeys and related RepoId's
- Frame Number/matching Frame Number
- names of registered GIOP subdissectors and the RepoIds they 
  are interested in.


Also, to make things easier for all of us, I come to the 2nd part
of this release.

"idl2eth" - an IDL to ethereal dissector code generator.

Yep, IDL goes in, and a dissector for that IDL is generated.
Its kinda simple at the moment, and doesn't automatically
generate the exception code (thats coming in a week or 2), but the
code does compile and handles a lot of IDL (see below).
I had a file called crazy.idl that looked pretty scary, sequences
of sequences of structs etc, and it seemed to work ok.

And, it does save a lot of typing (phew).

idl2eth is a python backend to omniidl, which is part of
the omniORB distribution, avaliable at 

http://www.uk.research.att.com/omniORB/

So, you can do the following.

1.  To write the C code to stdout.  

    idl2eth  <your file.idl>

    eg: idl2eth echo.idl

2. To write to a file, just redirect the output.

    idl2eth echo.idl > packet-test-idl.c


3. Copy dissector to ethereal tree, edit makfile
   and compile !!!


I have the following  examples which are decoded fully
and can be COMPLETELY GENERATED from idl2eth.


sayHello
--------
example where server (servant) echo's a string

java_echo
---------
a more detailed IDL implementation, that exercises
many of the IDL types, including "any".


Bugs/Improvements
-----------------
- improve idl2eth
- Improve GIOP API, See  TODO inside packet-giop.c 

There are some unfinished things, but I am sure its
better to release now, and improve as we go along.
("release often, release early")

I am not sure where in the Ethereal tree that
idl2eth belongs (perhaps tools), but I leave that
to you.

Images.

snapshot01.png - nested anys (phew)
snapshot02.png - typeCode ,string
snapshot03.png - an operation returning a float
snapshot04.png - an IOR from a REPLY to REQUEST(resolve)

3. Logs
-------

Hello.log - for Hello.idl
Echo.log - for Echo.idl, look for any's and any's inside
            any's (phew), and IORs.


Where to go from here
---------------------

1. Auto Generate some good dissectors for stuff like
   - CosNaming
   - CosEvent etc.. so we can handle other IDL defined
     traffic.

2. Test Test Test, there are bugs I am sure !

3. Handling of wtsring and wchar.

4. Improve idl2eth

5. Improve GIOP api

Thanks
------

Thanks to my manager Lalin Sourjah (lalin.sourjah@xxxxxxxxxxxx)
for his support on this work.

Regards / Frank..

-- 
EUS/SV/Z Frank Singleton      ASO Americas BSS
Office : +1 972 583 3251      ECN 800 33251  
Mobile : +1 214 228 0874      Amateur Radio: VK3FCS/KM5WS   
Email : frank.singleton@xxxxxxxxxxxx

Hardware: HP Omnibook 4150 running Redhat Linux 6.2 (2.2.16 kernel).

Attachment: giop_rel.tgz
Description: Binary data