[OpenAFS-devel] Re: Windows error ERROR_REQ_NOT_ACCEP

[Ben Creech]

Disclaimer: This is mostly conjecture, as I have no familiarity with either 
NetBIOS communication or this code.

The failing function in my application logs is smb_ReceiveV3SessionSetupX 
in smb3.c.  Once the AFS Client goes into zombie mode, this function always 
returns CM_ERROR_REMOTECONN, like so:
    if (vcp->flags & SMB_VCFLAG_REMOTECONN)
        return CM_ERROR_REMOTECONN;

The only place in the code that SMB_VCFLAG_REMOTECONN is set is by the smb 
listener daemon's main loop (in smb.c).  Every time the daemon loop 
processes a packet, it checks the machine name on the source against 
GetComputerName.  If the match fails, and the client isn't in Gateway mode 
(which none of my machines are), it adds that flag to a "flags" variable:
		if (!isGateway)
			if (strncmp(rname, cname, NCBNAMSZ) != 0)
				flags |= SMB_VCFLAG_REMOTECONN;

eventually the contents of "flags" are or'd into the virtual circuit 
pointer (?):
                vcp = smb_FindVC(ncbp->ncb_lsn, SMB_FLAG_CREATE, 
ncbp->ncb_lana_num);
		vcp->flags |= flags;
                strcpy(vcp->rname, rname);

The vcp pointer is eventually dispatched to smb_ReceiveV3SessionSetupX, 
which checks the flag and subsequently returns failure.

I think the problem is that the "flags" variable is not reset at the end of 
the loop.  Thus, every subsequent packet on that lan adapter will get 
marked as being "remote", until the whole service is restarted.

I suppose I shall recompile the AFS client with a flags=0 towards the 
beginning of the daemon loop.  This raises the question: does the current 
release compile on vs.net?  Does the latest snapshot?  I think James 
Peterson was working on this, but I'm not sure what state it's in.