Nir Soffer wrote: > > > Nir Soffer wrote: > > > > > > > > On a Linux machine, running Samba 2.2.4, we got this > > error message: > > > > > > > > > > Aug 7 01:47:01 node1-mgmt winbindd[7034]: [2002/08/07 > > 01:47:01, 0] > > > > > rpc_client/cli_pipe.c:rpc_api_pipe(359) > > > > > Aug 7 01:47:01 node1-mgmt winbindd[7034]: cli_pipe: > > > > return critical > > > > > error. Error was SUCCESS - 0 > > > > > > > > > > Previous to that error message, winbindd ran without fault > > > > for nearly 30 > > > > > days. > > > > > > > > The DC 'went away'. (Which closed the pipe, and left 0 > > in the error > > > > feild - yes we need a better way do handle this...). > > > > > > I guessed something to that effect, but I don't believe something > > > happened to the DC, that's what's bothering me. I'll need > > to check that > > > out. > > > > > > So if hit this DEBUG statement > > > DEBUG(0, ("cli_pipe: return critical error. Error was %s\n", > > > cli_errstr(cli))); > > > > > > When the error is 0 I should: > > > > > > DEBUG(0, ("cli_pipe: Critical error - the pipe has closed. > > The DC has > > > probably been disconnected") ) > > > > > > or something? > > > > > > need a patch? > > > > I'll take a patch that actually does the real job - that code needs to > > be 'upgraded' to NTSTATUS. Follow the functions, and you will > > eventually get to 'cli_receive_smb()'. This is what is generating the > > error - so it should probably get the DEBUG(), and a sensible NTSTATUS > > value should be returned down the chain. > > Tracking down the code leads me at the end to receive_smb, which > probably returns a false when it fails to receive anything. But then > again, it could fail on anything, so nailing it down there seems wrong. > > client_receive_smb appears to be merely a wrapper for receive_smb... > > Ugh. This stuff is hairy. What exactly needs to happen? Does the code > have to see if there's BOTH an error from client_receive_smb, and if > there's no status set, and then conclude all it is is a broken link?
If receive_smb fails, then the server has cut the link. At this point we should unconditionally return a particular NTSTATUS error. I don't know which one yet - pick one from include/nterr.h > > It's really the BOOLs everywhere that causes the problem. > > I haven't figured that one out yet - > > A. What exactly _is_ the construct for keeping a status code, from > looking at clierrstr I see that there are 3 classes of error message, > each handled sepreately and differently (RAP messages, whatever the hell > they may be, NT STATUS messages, and DOS and SMB messages (?!) which are > apparently handled together? (?!?) We can be sent either a DOS or an NT error. DOS errors are a pain to deal with, so we normally convert these to NTSTATUS values > B. Why not return an int value that some meaning like most C functions > do? Thats what the NTSTATUS is, it's a uint32 dressed up in such a way that it is assignment incompatible with int, becouse we got a *lot* of bugs with people getting it and BOOL confused, and therefore using the wrong 'if' test on it. (0 for succcess as opposed to 1 for success). Andrew Bartlett -- Andrew Bartlett [EMAIL PROTECTED] Manager, Authentication Subsystems, Samba Team [EMAIL PROTECTED] Student Network Administrator, Hawker College [EMAIL PROTECTED] http://samba.org http://build.samba.org http://hawkerc.net