Win2k -> Samba 2.2.2 for IRIX

[Jeremy Allison]

On Wed, Dec 19, 2001 at 05:15:50PM -0600, Carrie Knox wrote:
> Hello,
> 
> I've been searching through the Samba archives attempting to
> find a resolution to intermittent Win2k -> Samba 2.2.2 for
> IRIX  share failures.  It seems that there have been
> numerous failures similar to mine reported with various
> versions of Samba and various OS's, but I've been unable to
> find a workable resolution.
> 
> Intermittently when connecting to a Samba share from Win2k
> systems I receive the error "The specified network name is
> no longer available".    After several (numerous) retries,
> the share will eventually be available, but not for long.
> It eventually disconnects again with these errors logged.
> [2001/12/14 09:52:43, 0] lib/util_sock.c:(1036)
>   getpeername failed. Error was Invalid argument
> [2001/12/14 09:52:43, 0] lib/util_sock.c:(540)
>   write_socket_data: write failure. Error = Broken pipe
> [2001/12/14 09:52:43, 0] lib/util_sock.c:(563)
>   write_socket: Error writing 4 bytes to socket 11: ERRNO =
> Broken pipe
> [2001/12/14 09:52:43, 0] lib/util_sock.c:(727)
>   Error writing 4 bytes to client. -1. (Broken pipe)
> 
> At the same time,  there is absolutely no problem connecting
> 
> to the same share from Windows NT4 systems.
> 
> I'm currently running Samba 2.2.2 on an IRIX 6.5.9m server.
> 
> I decided to try using something other than the default
> netbios name (dns name) in my smb.conf file and low and
> behold the Win2k systems have  no problems connecting to the
> share as long as the netbios name is different than the dns
> hostname.
> 
> Does anyone have experience with this Win2k -> Samba
> behavior?
> Thanks,

write_socket_data: write failure. Error = Broken pipe
means the client has dropped the connection. Use tcpdump
or some other TCP analysis tool to determine who sends the
RST or FIN packet (and maybe why). This is at a layer below
Samba. It may be an incompatibility at the TCP layer, although
this is unlikely. But remember SMB traffic can stress TCP
a lot - it transfers a lot more data and is a lot longer
lived than the typical http request.

Jeremy.