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?
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
+ 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
--
Alex Hooper | <w> www.bmjpg.com
Systems and Database Administration | <e> [EMAIL PROTECTED]
BMJ Knowledge, BMJ Publishing Group | <t> +44 20 7383 6049
BMA House, LONDON, WC1H 9JR |
_______________________________________________________________________
The BMJ Group is one of the world's most trusted providers of medical
information for doctors, researchers, health care workers and patients
www.bmjgroup.bmj.com. This email and any attachments are confidential. If you
have received this email in error, please delete it and kindly notify us. If
the email contains personal views then the BMJ Group accepts no responsibility
for these statements. The recipient should check this email and attachments
for viruses because the BMJ Group accepts no liability for any damage caused by
viruses. Emails sent or received by the BMJ Group may be monitored for size,
traffic, distribution and content. BMJ Publishing Group Limited trading as BMJ
Group. A private limited company, registered in England and Wales under
registration number 03102371. Registered office: BMA House, Tavistock Square,
London WC1H 9JR, UK.
_______________________________________________________________________
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/listinfo/samba
