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