Re: patch for 2.1.66 smbfs, smbclient
Bill Hawes (whawes@star.net)
Sat, 29 Nov 1997 08:26:27 -0500
Chris Wedgwood wrote:
>
> Message-ID: <347F258A.F2F6A745@star.net>
> Date: Fri, 28 Nov 1997 15:11:54 -0500
> From: Bill Hawes <whawes@star.net>
> MIME-Version: 1.0
> To: linux-kernel@vger.rutgers.edu
> CC: Chris Wedgwood <chris@f00f.org>,
> Volker Lendecke <lendecke@math.uni-goettingen.de>
> Subject: patch for 2.1.66 smbfs, smbclient
>
> The attached patch for 2.1.66 smbfs and 1.9.17p1 smbclient should take
> care of at least some of the problems with reconnecting to a server.
>
> OK...
>
> [me:3] caffeine:~$ cat /proc/mounts|grep smbfs;echo;netstat|grep ssn
> <NULL> /mounts/helpdesk smbfs rw 0 0
>
> tcp 0 0 192.168.0.2:1025 server1.ix.:netbios-ssn CLOSE
>
> -- So it's mounted the the NT box has closed the connection...
>
> [me:3] caffeine:~$ ls -l /mounts/helpdesk
> smb_trans2_request: result=-32, setting invalid
> smb_retry: timed out, try again later
> smb_proc_readdir_long: error=-32, breaking
> smb_refill_dircache: readdir failed, result=-32
> total 0
>
> -- and again...
>
> [me:3] caffeine:~$ ls -l /mounts/helpdesk
> smb_retry: timed out, try again later
> smb_proc_readdir_long: error=-5, breaking
> smb_refill_dircache: readdir failed, result=-5
> total 0
>
> -- smbclient doesn't get any signals here...
> -- as root on another vt --
>
> [root:1] caffeine:~# kill -USR1 249
> [root:1] caffeine:~# smb_newconn: server not locked, count=1
> smb_offerconn: server not locked, count=1
> smb_offerconn: state valid, pid=249
Hi Chris,
You should never need to signal the smbclient process by hand -- every
retry attempt sends a signal. Take a look at smbfs/proc.c in
smb_retry() ...
I added some debugging printfs to smbclient that might help. You should
see it wake up and attempt to open the sockets every time smbfs enters
the retry code.
> I'm not sure what this will do to open files though... (or indeed if there
> are file open as to whether the connection will be closed in the first
> place).
>
> In theory... the remote end could reboot. Any access to open files should
> probably return EIO or something similar. (This probably also means checking
> upon close(2) if a file was R/W and returning and error here).
Open files can't persist from connection to connection -- the server
resets them each time. This is handled in smbfs by setting the open flag
to server->generation, which is incremented each time.
Regards,
Bill