Ethereal-dev: Re: [Ethereal-dev] Changing dissect_rpc_data which is called from dissect_nfsdat
On Tue, 20 May 2003, Guy Harris wrote:
> On Tue, May 20, 2003 at 12:10:00AM -0700, Richard Sharpe wrote:
> > 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.
>
> OK, so this is for the SECINFO reply, not for anything else in NFSv4 or
> for anything else in any other ONC RPC protocol.
OK, now that I have looked at RFC3430, I can see that this info is defined
at the NFSv4 layer, which puts a different complection on this.
> > 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 ...
>
> If it's *not* an ASN.1 OID, it's a broken implementation, at least as I
> read RFC 3010:
It looks like an ASN.1 OID to me ... I just hadn't figured out that it was
NFSv4 that was specifying the auth-mech triple rather than RPCSEC_GSS.
> Given that, I'd say that this is an issue of truly-opaque data (such as
> the data in read replies and write requests) vs. "opaque" data whose
> format is defined by something outside RPC/XDR. There are several ways
> in which the latter could be handled, such as:
>
> 1) have "dissect_rpc_data()" take an extra argument, and modify
> all the calls (presumably a null function pointer means "it
> truly is opaque"), and have "dissect_nfsdata()" pass on its
> extra argument;
>
> 2) add "dissect_rpc_data_ex()", have "dissect_nfsdata()" call it
> instead of "dissect_rpc_data()", and pass on an extra
> argument;
>
> 3) have "dissect_rpc_opaque_data()" take an extra argument,
> modify the few calls there are to *it*, export it from
> "packet-rpc.c", have "dissect_nfs_rpcsec_gss_info()" call
> "dissect_rpc_opaque_data()", and don't change
> "dissect_nfsdata()" (except perhaps to eliminate it in favor
> of calling "dissect_rpc_data()" directly!) or
> "dissect_rpc_data()" at all.
>
> My preference is for 3) - modifying "dissect_nfsdata()", which is called
> in many places, most of which *aren't* ASN.1 OIDs, seems to me to be the
> wrong solution, and tweaking "dissect_rpc_opaque_data()" requires the
> fewest calls to be changed *AND* might even allow us to get rid of the
> "string_data" Boolean argument to "dissect_rpc_opaque_data()" in favor
> of passing it a "show this as a character string" routine.
OK, I tend to agree. I will have to clean up my sandbox, but I can do that
tomorrow ...
Thanks for the feedback.
Regards
-----
Richard Sharpe, rsharpe[at]ns.aus.com, rsharpe[at]samba.org,
sharpe[at]ethereal.com, http://www.richardsharpe.com
