[Craig Rodrigues <rodrigc@xxxxxxxxx>]

On Fri, Feb 14, 2003 at 11:12:58AM -0800, Guy Harris wrote:
> Yes, but that would mean that Ethereal would, once again, report packets
> in the capture that I'll send you (under separate cover) as malformed,
> and would, for example, get the Request id, Response expected, and
> Object Key length fields in the first of those packets wrong.

The packet trace that you have is generating non-compliant
GIOP.

In your patch, you added:

   4787     if (seqlen_cd == 0)
   4788       continue;
   4789
   4790     /* Skip the byte-order octet */
   4791     seqlen_cd -= 1;
   4792
   4793     if (seqlen_cd == 0)
   4794       continue; /* what is the byte order of one hand clapping? */
   4795



Well, you can't skip the byte-order octet like that.

The packet trace you provided had a Service Context ID of 1 (CodeSets).
Section "13.7.1 Standard Service Contexts" of the CORBA 3.0.2 
standard states that CodeSets is a CDR encapsulation of the following
of a CONV_FRAME::CodeSetContext.  This structure is defined on
page 13-45 of the CORBA 3.0.2 standard as:

module CONV_FRAME {
  typedef unsigned long CodeSetId;
  struct CodeSetContext {
     CodeSetId  char_data;
     CodeSetId  wchar_data;
  };
};


The rules for CDR encapsulation are stated in
Section "15.3.3 Encapsulation" as follows:

"When encapsulating OMG IDL data types, the first
 octet in the stream (index 0) contains a boolean value indicating
the byte ordering fo the encapsulated data.

.
.
.
Marshaled data are aligned relative to the beginning
of the octet stream (the first octet of which is occupied by the
byte order flag)."

So you can't ignore the byte order flag in the CDR encoded
buffer, because it is necessary for correctly decoding data in
the buffer on the correct alignment boundaries.  Compliant ORB's get
this right, including TAO 1.3.

You can't even put a special case for service context id 1, because
it is a CDR encapsulated structure, and must follow the CDR encapsulation
rules.  Also, the rules for CDR encapsulation are the same
for all GIOP versions, so even though your trace contained GIOP 1.0
data, where the service context is at the beginning of the GIOP Request 
header, it is still bad data.

Your GIOP packet trace is unfortunately no good because it contains
missing and consequently misaligned data.  It is being generated
by a non-compliant ORB product.


The other thing that is wrong with your patch is that
you do get_CDR_encap_info() *before* checking the vcsid and scid.

This is wrong.  Even though the OMG specified service contexts
are CDR encapsulated, it is legal for someone to use
a vcsid > 0 (OMG reserves vcsid ==0) and put whatever junk they
want in the context_data field, even if it is not CDR encapsulated.

Can you revert your patch?

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