if during recv we received an error, then propagate that to the caller.
otherwise, do time out check. also do timeout check if the thread's xid
didn't match received xid (making sure we'll timeout if we have a starving
thread that will never receive a reply)
once libtirpc blocking recv was changed to a polling receive,
we no longer had a timeout mechanims on waiting for a reply.
solution: save a timestamp before the recv call, on each async recv return
check if the time lapsed does not exceed the timeout value. when timeout
is reach, return TIMEDOUT rpc error.
nfs41_cb_session stores the last cb_compound reply (whether or not cachethis was set) to handle retry attempts, along with the cb_compound arguments for improved NFS4ERR_SEQ_FALSE_RETRY detection
Signed-off-by: Casey Bodley <cbodley@citi.umich.edu>
MIT KDC don't issue tickets that are better than 1K.
Windows KDC carry authorization payloads with their service tickets
and thus much bigger than MIT's tickets.
we already drop the lock between sending and receiving the rpc packets. now making it so that receive doesn't block for too long (ie 100ms) before unlocking the socket. this is needed for the callback. original rpc is sent and it triggers a callback from the server. we fork another thread to handle it, ie it needs to send a deleg_return rpc. if original rpc gets control and blocks on trying to receive its reply, it'll timeout and original rpc will return an error. instead we need to not block for long and allow the deleg_return to go thru so that the server can reply successfully to the original rpc.
note: privacy will not work when we have more than 1 outstanding rpcs which generates out of order replies which sspi does not allow when privacy is enabled.
adding auth_wrap() and auth_unwrap() to per-message gss token protection required adding these methods to auth_sys and auth_non.
linux server doesnt support v2 kerberos tokens that have rotated data. sspi will always produce such tokens for aes. thus thus code was only tested for v1 kerberos tokens (ie des).
(a) auth_refresh recursively calls clnt_call() which will call
clnt_vc_call() and will try to acquire a lock on the socket which we have
already acquires. thus a change to see if the thread trying to acquire the
lock is the same holding the lock.
(b) authsspi_fresh() needed to check if we were called to refresh the
context due to the error (ie 2nd argument non-null) and if so, destroy
the old context and then reacquire a new sspi context.
it seems that InitializeSecurityContext() also requires new creds as well
so after initially calling AcquireCreds() we don't need to worry about
refreshing credentials.
