Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!comp.vuw.ac.nz!cc-server4.massey.ac.nz!G.Eustace
From: G.Eustace@massey.ac.nz (Glen Eustace)
Newsgroups: comp.protocols.nfs
Subject: Re: Password program needed.
Message-ID: <1990Dec12.185512.680@massey.ac.nz>
Date: 12 Dec 90 18:55:12 GMT
References: <1741@fornax.UUCP> <90342.015839TOMIII@MTUS5.BITNET> <3589@jaytee.East.Sun.COM>
Organization: Massey University, Palmerston North, New Zealand
Lines: 37
X-Reader: NETNEWS/PC Version 2.2

I second Geoff's statements re: password authentication.  We have
been using a home grown daemon to do exactly that ( It returned a lot
of other information as well ).  I have recently changed over to
using an RPC call to check with pcnfsd before spawning the NET NAME.

As part of the above excercise I seem to have struck what appears to
be a buggy part of the toolkit.  I originally wanted to do the
following,

clntudp_create()

clnt_call()...clnt_call()...clnt_call()...clnt_call()...

clnt_destroy()

the first clnt_call almost always fails with error 3.

callrpc()....callrpc()....callrpc()....callrpc()....

however works.

In a trivial program, the prior example usually works, it is only in
the larger program that things really come unstuck.  In trying to
trace what is happening, it looks like somewhere in udp_open(), areas
of the programs data are arbitrarily overwritten.  I would guess that
in the trivial case nothing of importance is being overwritten.  As
an aside, both the trivial case and it's larger cousin work fine when
compiled on the unix host.

Anyone any ideas?


-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Glen Eustace, Software Manager, Computer Centre, Massey University,
Palmerston North, New Zealand.        EMail: G.Eustace@massey.ac.nz
Phone: +64 63 69099 x7440, Fax: +64 63 505 607,    Timezone: GMT-12