Samba login

[David Collier-Brown]

Nagy Tamás wrote:
> I've  noticed that  when  the inner  network is  slightly  loaded, the
> computers
> farther on (the) linux, couldn't enter the network. It's because (the)
> linux
> doesn't allow them to  enter. 

> In that  case when  (the) linux didn't  allow me to enter,  in the log
> file I
> found things like that:
> 
> [2000/10/31   11:17:31,    0]   lib/util_sock.c:write_socket_data(537)
>     write_socket_data:   write    failure.   Error   =   Broken   pipe
> [2000/10/31     11:17:31,     0]     lib/util_sock.c:write_socket(563)
>   write_socket:  Error writing  4 bytes to  socket 11: ERRNO  = Broken
> pipe
> [2000/10/31      11:17:31,       0]      lib/util_sock.c:send_smb(751)
>   Error writing 4 bytes to client. -1. Exiting

 	You actually should have asked this question in the 
	samba at samba.org mailing list: samba-technical is about 
	developing new versions of Samba.

  	However, you're seeing the client disconnct for some 
	reason: the problem is finding out the reason so the
	team can fix the $#^!&*!!### thing.

	I'm attaching a note on diagnosing it: anyone want to
	add to or improve it, oh real experts?

--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
-------------- next part --------------
Diagnosing "Broken Pipe" errors.
===============================

  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
or
	[2000/10/05 11:08:16, 0] lib/util_sock.c:read_socket_data(477)
	 read_socket_data: recv failure for 1252. Error = Connection reset
	 by peer

  These are unexpected client disconnections, as seen by Samba.
Interestingly, they can also cause the client to report "The network is 
busy" while trying to (re-)map the file.

  If you happen to be using security = server, the Samba messages
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 bad drivers for ethernet cards (especially on 
Windows ME) or 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