Ethereal-dev: Re: [Ethereal-dev] Changing dissect_rpc_data which is called from dissect_nfsdat

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

Date Index Thread Index Other Months All Mailing Lists
Date Prev Date Next Thread Prev Thread Next
From: Richard Sharpe <rsharpe@xxxxxxxxxxxxxxxxx>
Date: Tue, 20 May 2003 00:10:00 -0700 (PDT)
On Mon, 19 May 2003, Guy Harris wrote:

> On Mon, May 19, 2003 at 11:49:27PM -0700, Richard Sharpe wrote:
> > In trying to provide better GSSAPI (RPCSEC_GSS) support in NFSv4, I needed 
> > to change dissect_nfsdata to pass it a function for dissecting the content 
> > if the caller knows the type of data. 
> 
> Why is stuff that happens to be dissected by "dissect_nfsdata()" any
> different from anything else in RPCSEC_GSS-authenticated RPC calls?
> 
> Does the RPC layer even *know* what stuff would be dissected by that in
> Ethereal?
> 
> I'd expect the GSSAPI stuff to be done entirely at the RPC layer; what
> am I missing here?

We know at the NFSv4 layer, it seems, that there is an OID in the opaque 
data ... it seems that the RPC layer doesn't necessarily know that info.

This data is in the secinfo reply. The nfs layer knows that it is dealing 
with RPCSEC_GSS data ... The following routine is only called for handling 
the secinfo data in a reply to a request that specifies secinfo.

static int
dissect_nfs_rpcsec_gss_info(tvbuff_t *tvb, int offset, proto_tree *tree)
{
        /*
         * What we have in the first portion is an OID, so dissect it the
         * correct way
         */
        offset = dissect_nfsdata(tvb, offset, tree, hf_nfs_sec_oid4, 
NULL);
        offset = dissect_rpc_uint32(tvb, tree, hf_nfs_qop4, offset);
        offset = dissect_rpc_uint32(tvb, tree,
                hf_nfs_secinfo_rpcsec_gss_info_service, offset);

        return offset;
}

I don't want to call the GSSAPI dissector just to dissect an OID, and in 
any case, it seems that it is an ASN1 OID, not a GSSAPI token at this 
stage, which might mean that the people who sent me the capture have a 
broken implementation ...

I also don't want to encumber that code with a manual dissection of the 
OID, at this stage, at least ...

I also can't find in RFC2203 where it specifies the format of the secinfo 
reply, so it seems to be implementation defined :-(

Regards
-----
Richard Sharpe, rsharpe[at]ns.aus.com, rsharpe[at]samba.org, 
sharpe[at]ethereal.com, http://www.richardsharpe.com