[Samba] Re: Samba and the InterWeb

[Scott Lovenberg]

Alex Hooper wrote:
> Scott Lovenberg uttered:
>> Alex Hooper wrote:
>>> Hi,
>>>
>>> We have an office-based Windows-locked publishing system whose only 
>>> delivery mechanism is to write to a local filesystem, and a 
>>> requirement for its output to be available to a collocated production 
>>> environment comprising Solaris and Linux boxes. The 'obvious' 
>>> solution was to run a Samba server on one of the collocated Linux 
>>> boxes and mount the share it provides on the relevant Windows 
>>> machines in the office. And this is what I have done. This works, but 
>>> encounters the problem I am about to describe.
>>>
>>> SCENARIO ONE:
>>>
>>> Connecting to the server/share in Explorer (Windows XP) by typing the 
>>> path (\\dns.host.name\share) into the address bar is accomplished 
>>> without problem, as is receiving a directory listing. But uploading a 
>>> file to the remote share (by drag and dropping) causes Explorer to 
>>> freeze for anything between 10 and 30 seconds after which the file 
>>> transfers at good speed.
>>>
>>> SCENARIO TWO:
>>>
>>> Map the remote share, using same connection details. Now copy is 
>>> often fine, but sometimes will just fail with a "Cannot copy
>>> <filename>: The specified network name is no longer available." and 
>>> leave a zero-length file at the remote end.
>>>
>>> Not infrequently, smbd processes are being left in an 
>>> 'uninterruptible sleep' state.
>>>
>>> If I mount the remote share via smbmount onto a Linux server in the 
>>> office, I don't encounter any of these problems.
>>>
>>> Packet-sniffing on scenario one shows that the pause is happening 
>>> before  any set-up for the file transfer: it looks like the client 
>>> disconnects, then there's a pause, then it reconnects.
>>>
>>> I'm using Samba version 3.0.25b-1.el4_6.4 on RHEL ES release 4. 
>>> Clients are Windows XP Pro. Our office has a fairly large and complex 
>>> LAN which is managed by a separate department. Access to the Internet 
>>> is, not surprisingly, via a NATting gateway. Appropriate ports have 
>>> been opened in the firewalls, though all communication is in 
>>> Direct-hosted mode (ie, I only see traffic on port 445/tcp).
>>>
>>> smb.conf looks like this:
>>>
>>> [global]
>>>
>>>         workgroup = WG123
>>>         netbios name = n2323  # hostname of server
>>>         server string = FOO-BAR-Samba
>>>
>>>         #wins proxy = yes
>>>         #wins server = xxx.xx.xx.x
>>>
>>>         security = user
>>>         passdb backend = tdbsam
>>>
>>>         load printers = no
>>>
>>>         # idle time (mins) before client is disconnected
>>>         dead time = 15
>>>         keepalive = 10
>>>         socket options = IPTOS_THROUGHPUT SO_SNDBUF=8576
>>>         inherit permissions = yes
>>>
>>> [test-xml]
>>>         path = /stuff/test-xml
>>>         writeable = Yes
>>>         public = no
>>>
>>> Could anyone suggest what might be going on here?
>>>
>>> Thanks,
>>>
>>> Alex.
>> On scenario1, is it (Windows client) trying to connect to port 445 on 
>> the server, being dropped instead of rejected, timing out, and then 
>> establishing a connection on port 139?  I think by default Windows 
>> tries to connect to both at the same time or something weird like that.
>>
> 
> No. There is no attempt to use port 139: only 445 is approached.
> 
>>
>> On scenario2, I've seen behavior something akin to this on a corrupted 
>> e1000 kernel module.  I've also seen bad cables (twice where gigabit 
>> and mii are concerned, IIRC) that behave all kinds of weird, at any 
>> given moment.
>>
> 
> The server's using the bnx2 module and the NIC is at 100MB FD. I'm not 
> noting any other network weirdness, which would seem to suggest cabling 
> is probably OK, wouldn't it?
> 
  I once heard a quote (which I'd like to attribute to Jeremy Allison 
for some reason) to the effect of "The Windows SMB network stack is like 
a canary in a coal mine, when you have network troubles it's the first 
thing to die."  I could get everything else to work just fine with this 
driver, but SMB/CIFS just kept flaking out.  So, I always try to trace a 
problem starting from the wall back.

>> Anyways, FWIW, how does your 'netstat -s' output look?  Are you 
>> getting a considerable number of connection resets being sent or 
>> received?
>>
> 
> No. All the "reset sent"s in the diff below belong to an unrelated 
> application. In the time between the two netstats compared below, 
> various stalling transfers were made and one "network name is no longer 
> available" was received:
> 
> # diff -Bub /root/netstat-20080213-0939 /root/netstat-20080213-1016
> --- /root/netstat-20080213-0939 2008-02-13 09:39:24.000000000 +0000
> +++ /root/netstat-20080213-1016 2008-02-13 10:16:34.000000000 +0000
> @@ -1,43 +1,44 @@
>  Ip:
> -    4336 total packets received
> +    21933 total packets received
>      0 forwarded
>      0 incoming packets discarded
> -    4335 incoming packets delivered
> -    4134 requests sent out
> +    20292 incoming packets delivered
> +    19069 requests sent out
>  Icmp:
> -    26 ICMP messages received
> +    92 ICMP messages received
>      0 input ICMP message failed.
>      ICMP input histogram:
> -        echo requests: 26
> -    26 ICMP messages sent
> +        echo requests: 92
> +    92 ICMP messages sent
>      0 ICMP messages failed
>      ICMP output histogram:
> -        echo replies: 26
> +        echo replies: 92
>  Tcp:
> -    6 active connections openings
> -    161 passive connection openings
> +    11 active connections openings
> +    169 passive connection openings
>      0 failed connection attempts
> -    0 connection resets received
> -    93 connections established
> -    4176 segments received
> -    3992 segments send out
> +    1 connection resets received

Hrm... the client reset.  Do you have a wire sniff to see what is going 
on right before the client sends a reset?

> +    97 connections established
> +    18529 segments received
> +    17417 segments send out
>      0 segments retransmited
>      0 bad segments received.
> -    259 resets sent
> +    333 resets sent
>  Udp:
> -    132 packets received
> +    1663 packets received
>      0 packets to unknown port received.
>      0 packet receive errors
> -    116 packets sent
> +    1560 packets sent
>  TcpExt:
>      ArpFilter: 0
> -    74 TCP sockets finished time wait in fast timer
> -    18 delayed acks sent
> -    3191 packets directly queued to recvmsg prequeue.
> -    396 packets directly received from prequeue
> -    2006 packets header predicted
> -    TCPPureAcks: 969
> -    TCPHPAcks: 1773
> +    78 TCP sockets finished time wait in fast timer
> +    880 delayed acks sent
> +    14318 packets directly queued to recvmsg prequeue.
> +    1431219 packets directly received from prequeue
> +    10014 packets header predicted
> +    1063 packets header predicted and directly queued to user
> +    TCPPureAcks: 1612
> +    TCPHPAcks: 10445
>      TCPRenoRecovery: 0
>      TCPSackRecovery: 0
>      TCPSACKReneging: 0