Samba Drops Connections

[David Collier-Brown]

I'm having problems with Samba dropping connections on the network. 
We've recently installed a Cisco Catalyst switch, if that makes a
difference, but the log for one of the machines is as follows - 

52
[2000/09/13 12:09:28, 1] smbd/service.c:close_cnum(557)
  h77 (0.0.0.0) closed connection to service xx
[2000/09/13 12:09:35, 1] smbd/service.c:make_connection(521)
  h77 (12.1.1.23) connect to service xx as user xx (uid=xxx, gid=xxx)
(pid 23254)
[2000/09/13 12:10:15, 0] smbd/oplock.c:oplock_break(922)
  oplock_break: receive_smb timed out after 30 seconds.
  oplock_break failed for file XXXXXX.XLS (dev = 806, inode =
1550639).
[2000/09/13 12:10:15, 0] smbd/oplock.c:oplock_break(992)
  oplock_break: client failure in break - shutting down this smbd.
[2000/09/13 12:10:15, 1] smbd/service.c:close_cnum(557)

[and oplocks are off]

  I think the oplock break is a misleading message (although it
also may indicate a samba error).
  The connection to the client is broken, and smbd is complaining
that it has to shut down: this may indicate an error in the
connection between samba and the client.

This is a copy of a message I sent to someone else about
this problem
-------------  
  Every so often these days (circa win98, win2k), we see error
messages 
like the following showing up in the logs:
        [2000/09/08 18:06:24, 0]
         /usr/ports/net/samba/work/samba-2.0.6/source/lib/util_s
         ock.c:write_socket_data(537)
         write_socket_data: write failure. Error = Broken pipe

  These are unexpected client disconnections, as seen by Samba.

  If you happen to be using security = server, these can be 
eliminated by setting keepalive = 0.  If you are using any
other security setting, use keepalive = 30 to tell Samba to
clean up more often (this won't reduce the messages, though!)

  They usually indicates an error by the client, which caused
it to
        1) blue screen
        2) reboot
        3) silently disconect and reconnect.
	
  The latter is the annoying one... 

  The usual cause is a networking problem.  What the team's seen
a lot lately are mismatches between ethernet cards and hubs...

  Both ends of each connection between a hub and a machine must 
be running at the same speed, either 10 or 100 Mbit/S and at the 
same duplex setting (half- or full-duplex, sometimes called simplex 
and duplex).

  A mismatch is usually detectable using ftp: if copying in one 
direction is an order of magnitude fast than the other, you have 
a problem. Note that being a little slower one way than the other
is normal: my machine at work looks like this:  

ftp> get gnuplot-3.7-sol8-sparc-local foo 
200 PORT command successful.  
150 ASCII data connection for gnuplot-3.7-sol8-sparc-local
(129.155.8.39,39390) 
(1159384
bytes).  
226 ASCII Transfer complete.  
local: foo remote: gnuplot-3.7-sol8-sparc-local 
1163024 bytes received in 1.2 seconds (955.88 Kbytes/s)

ftp> put foo foo
200 PORT command successful.
150 ASCII data connection for foo (129.155.8.39,39394).
226 Transfer complete.
local: foo remote: foo
1163024 bytes sent in 0.45 seconds (2520.48 Kbytes/s)

  So the "get" is 37% of the "put" speed (the put is writing to a 
slower disk than the get was).


  Looking at ethernet stats can help, too: netstat -i output
should look something like:

 Name  Mtu  Net/Dest Address        Ipkts  Ierrs Opkts  Oerrs Collis
Queue 
lo0   8232 loopback localhost      1904006 0     1904006 0     0     
0     
hme0  1500 elsbeth  elsbeth        8278338 1     2280982 0     579602
0 

  The number of errors should be **very** low: I have about
1 in 12,100,000.

  The number of collisions should be below 3% UNLESS you have
a cut-through (first generation) ethernet hub. I have 25.4%
because I have a cut-through hub on this machine.

  The failing client can be found by using smbstatus repertedly.
Look at the "pid" column:

Samba version 2.0.7
Service      uid      gid      pid     machine
----------------------------------------------
temp         davecb   staff    18310   elsbeth  (129.155.8.39) Tue Sep
12 07:49:
40 2000

  If elsbeth had been failing and reconnecting, a previous 
smbstatus would have looked the same, but the pid would be
different, as Samba starts a new process on each (re-)connection.


--dave

-- 
David Collier-Brown,  | Always do right. This will gratify some people
185 Ellerslie Ave.,   | and astonish the rest.        -- Mark Twain
Willowdale, Ontario   | //www.oreilly.com/catalog/samba/author.html
Work: (905) 415-2849 Home: (416) 223-8968 Email: davecb at canada.sun.com