[Samba] Re: Samba and the InterWeb
scott.lovenberg at gmail.com
Wed Feb 13 16:34:13 GMT 2008
Alex Hooper wrote:
> Scott Lovenberg uttered:
>> Alex Hooper wrote:
>>> 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:
>>> 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
>>> path = /stuff/test-xml
>>> writeable = Yes
>>> public = no
>>> Could anyone suggest what might be going on here?
>> 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
> 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 @@
> - 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
> - 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
> - 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
> - 132 packets received
> + 1663 packets received
> 0 packets to unknown port received.
> 0 packet receive errors
> - 116 packets sent
> + 1560 packets sent
> 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
More information about the samba