On Thu, 22 May 2003, Mike Frisch wrote:
> On Thu, May 22, 2003 at 02:13:21PM -0700, Richard Sharpe wrote:
> > According to my reading of RFC3530, 14.2.31, a SECINFO reply will contain,
> > if the status is NFSok, and array of structures containing the OIDs of the
> > mechanisms allowed.
> >
> > In particular, it is not a Value Follows followed by 0 or one sec info
> > structures ... which is how it is currently dissected ...
> >
> > Ahhh, I see the problem. packet-nfs.c has it coded to dissect a list
> > rather than an array!
>
> Feel free to fix it :) I wrote the dissector for NFSv4, but it has been
> a while since I've worked on NFSv4 and as such, the dissector may not be
> in sync with the current protocol specification. I have received ZERO
> feedback about the dissector, so I presume nobody is using it. I _know_
> it has bugs. A majority of the code was written long before a complete
> working NFSv4 client or server were available for testing.
No problems. This year appears to be the year of NFSv4 and there are
people working on the different secinfo flavors that can be accepted.
I have to implement some stuff I left out of the GSSAPI/SPNEGO dissectors
as well to handle everything they need.
> > BTW, why are the signatures for dissect_rpc_list and dissect_rpc_array
> > inconsistent? I would expect both of them to take an hf_index, or neither
> > to do so.
>
> Sorry, I cannot comment here. I have not looked at this code in a
> while.
If it is not too hard, I might fix that.
Regards
-----
Richard Sharpe, rsharpe[at]ns.aus.com, rsharpe[at]samba.org,
sharpe[at]ethereal.com, http://www.richardsharpe.com