Wireshark · Ethereal-dev: Re: [Ethereal-dev] packet-giop.c enhancements: ServiceContexts, RTCORBA priorities

[Craig Rodrigues <rodrigc@xxxxxxxxx>]

On Mon, Feb 17, 2003 at 05:14:39PM -0800, Guy Harris wrote:
> On Sat, Feb 15, 2003 at 09:10:47AM -0500, Craig Rodrigues wrote:
> > You *cannot* decrement the length of the sequence once it has
> > been advanced past the byte order octet.  The length of the sequence
> > is used for determining alignment when decoding the CDR encapsulated
> > buffer.
> 
> The *length* is used?  Not the *offset* of the first byte after the byte
> order octet?
> 
> That's *really* odd.  Are you certain that's the case?

I'm very certain I know what I am talking about.  I wrote most
of the original GIOP 1.2 parsing code, and have been working 
closely with ORB internals for the past few years, so am quite
familiar with this protocol from the perspective of a CORBA end-user
and also from the perspective of how ORB implementors implement the
protocol.  Your patch, while successfully dissecting the trace you
provided, messed up the dissection of RTCORBA priorities because
of alignment rules.

Can you please commit my patch which I sent in a previous e-mail, so that we 
can move on to other things?  My patch correctly handles your
trace, and also my traces with RTCORBA priority values.

Looking things up in the spec and explaining things is getting
very boring, and mildly annoying.  


> 	The high-order 24 bits of a service context ID contain a 24-bit
> 	vendor service context codeset ID (VSCID); the low-order 8 bits
> 	contain the rest of the service context ID.  A vendor (or group
> 	of vendors) who wishes to define a specific set of service
> 	context IDs should obtain a unique VSCID from the OMG, and then
> 	define a specific set of service context IDs using the VSCID for
> 	the high-order bits.  The VSCIDs of zero to 15 inclusive
> 	(0x000000 to 0x00000f) are reserved for use for OMG-defined
> 	standard service context IDs (i.e., service context IDs in the
> 	range 0- 4095 are reserved as OMG standard service contexts).
> 
> which speaks of VSCIDs in the range 0 through 15, and doesn't seem to
> say that the encapsulation rules for the context_data are different for
> OMG standard service contexts and vendor-specific service contexts.  Is
> that the intended implication?  (If so, it appears that the rules are
> that for VSCIDs in the range 0 through 15, it uses the 15.3.3
> encapsulation rules, not just for VSCID 0.)

The OMG has reserved those VSCID's, but they have only defined
16 SCID values for VSCID == 0.  The 16 SCID values which they have
defined are encapsulated.  However in the future, there is no
guarantee that new SCID values will be encapsulated.  When new
SCID values are specified, I don't mind modifying the dissector appropriately.

Also, as I mentioned in my previous e-mail, I have worked on projects
that have used proprietary VSCID values to pass binary context_data which 
does not follow encapsulation rules, because it is binary data.  Perfectly
fine to do this.

Now, my patch?

-- 
Craig Rodrigues        
http://home.attbi.com/~rodrigc
rodrigc@xxxxxxxxx