Very slow connection to Samba server - Mandriva

Hi,

When I connect to a Samba share (from XP) it takes a minute or two for
the connection to complete. Often it times out before any connection is
made.

Once connected operation is normal.

I've been googling for an answer but have found nothing useful.

I tried socket options = IPTOS_LOWDELAY TCP_NODELAY but that didn't make
a difference.

The only share I use is the [ct_backup] share which I use for backing up
the XP machine.

I've tried from a few different XP's, all have the same problem.

Other services like webmin and vnc work fine and connect without delay.

This is LM2008.0

Any ideas would be greatly appreciated.

Frank



Here's my /etc/samba/smb.conf file:

# Samba config file created using SWAT
# from 0.0.0.0 (0.0.0.0)
# Date: 2008/05/18 15:42:40

[global]
dos charset = 850
unix charset = ISO8859-1
workgroup = HOLO
netbios name = HOLO_SERVER
server string = Samba Server %v
security = SHARE
map to guest = Bad User
log file = /var/log/samba/%m.log
max log size = 50
socket options = IPTOS_LOWDELAY TCP_NODELAY
printcap cache time = 60
printcap name = cups
dns proxy = No
wins support = Yes
ldap ssl = no
preload = homes
default service = homes
printing = cups
print command =
lpq command = %p
lprm command =

[homes]
comment = Home Directories
read only = No
create mask = 0755
browseable = No

[printers]
comment = All Printers
path = /var/spool/samba
create mask = 0700
guest ok = Yes
printable = Yes
use client driver = Yes
browseable = No

[print$]
path = /var/lib/samba/printers
write list = @adm, root
inherit permissions = Yes
guest ok = Yes

[pdf-gen]
comment = PDF Generator (only valid users)
path = /var/tmp
printable = Yes
printing = bsd
print command = /usr/share/samba/scripts/print-pdf "%s" "%H" "//%L/%
u" "%m" "%I" "%J" &
lpq command = /bin/true
lprm command = lprm -P'%p' %j

[ct_backup]
comment = Chris's backup folder
path = /home/chris/backup
valid users = chris, ed
force user = chris
read only = No
wide links = No
delete readonly = Yes

On Tue, 20 May 2008 03:32:52 +0000, Frank Dreyfus wrote:

> Hi,
>
> When I connect to a Samba share (from XP) it takes a minute or two for
> the connection to complete. Often it times out before any connection is
> made.
>
> Once connected operation is normal.
>
> I've been googling for an answer but have found nothing useful.
>
> I tried socket options = IPTOS_LOWDELAY TCP_NODELAY but that didn't make
> a difference.
>
> The only share I use is the [ct_backup] share which I use for backing up
> the XP machine.
>
> I've tried from a few different XP's, all have the same problem.
>
> Other services like webmin and vnc work fine and connect without delay.
>
> This is LM2008.0
>
> Any ideas would be greatly appreciated.
>
> Frank
>
>
>
> Here's my /etc/samba/smb.conf file:
>
> # Samba config file created using SWAT
> # from 0.0.0.0 (0.0.0.0)
> # Date: 2008/05/18 15:42:40
>
> [global]
> dos charset = 850
> unix charset = ISO8859-1
> workgroup = HOLO
> netbios name = HOLO_SERVER
> server string = Samba Server %v
> security = SHARE
> map to guest = Bad User
> log file = /var/log/samba/%m.log
> max log size = 50
> socket options = IPTOS_LOWDELAY TCP_NODELAY
> printcap cache time = 60
> printcap name = cups
> dns proxy = No
> wins support = Yes
> ldap ssl = no
> preload = homes
> default service = homes
> printing = cups
> print command =
> lpq command = %p
> lprm command =
>
> [homes]
> comment = Home Directories
> read only = No
> create mask = 0755
> browseable = No
>
> [printers]
> comment = All Printers
> path = /var/spool/samba
> create mask = 0700
> guest ok = Yes
> printable = Yes
> use client driver = Yes
> browseable = No
>
> [print$]
> path = /var/lib/samba/printers
> write list = @adm, root
> inherit permissions = Yes
> guest ok = Yes
>
> [pdf-gen]
> comment = PDF Generator (only valid users)
> path = /var/tmp
> printable = Yes
> printing = bsd
> print command = /usr/share/samba/scripts/print-pdf "%s" "%H" "//%L/%
> u" "%m" "%I" "%J" &
> lpq command = /bin/true
> lprm command = lprm -P'%p' %j
>
> [ct_backup]
> comment = Chris's backup folder
> path = /home/chris/backup
> valid users = chris, ed
> force user = chris
> read only = No
> wide links = No
> delete readonly = Yes

Are you connecting by IP address or hostname?


CL

Frank Dreyfus wrote:

> When I connect to a Samba share (from XP) it takes a minute or two for
> the connection to complete. Often it times out before any connection is
> made.

At least partly this may be the WebDAV issue. XP by default tries to
make a webDAV connection when it mounts a share. It does this BEFORE
trying to make the actual SMB connection. If your samba server isn't
actually doing webDAV, and isn't actively rejecting them, there is a
lengthy timeout. I dealt with this in the firewall on my file server,
which does not also have a web server, where my notes say:

XP webDAV service tries to connect by default to Samba shares
if there's no web server it times out (slow), set it to reject (fast)
This decreases domain logins from 45 seconds to 17
Only other option is to
DOS>sc stop webclient
DOS>sc config webclient start= manual

My firewall is configured with a script and the relevant part is here:

if [ "$REJECT_HTTP" = "1" ]; then
get_ips $HTTP_REJECTS
for IP in "${IPS[@]}"; do
if [ "$VERBOSE" = "1" ]; then
echo Processing HTTP reject $IP...
fi
if [ "$CONNECTION_TRACKING" = "1" ]; then
$IPTABLEPROG -A INPUT -i $PUB_IFACE -p tcp \
-s $IP --sport $EPHEMERAL_PORTS \
-d $PUB_IP --dport 80 \
-m state --state NEW -j REJECT
fi

$IPTABLEPROG -A INPUT -i $PUB_IFACE -p tcp \
-s $IP --sport $EPHEMERAL_PORTS \
-d $PUB_IP --dport 80 -j REJECT

$IPTABLEPROG -A OUTPUT -o $PUB_IFACE -p tcp ! --syn \
-s $PUB_IP --sport 80 \
-d $IP --dport $EPHEMERAL_PORTS -j REJECT
done
fi

where HTTP_REJECTS is 131.215.0.0/16, or the entire campus network.
iptables --list shows the resulting rules like this:

REJECT tcp -- caltech-net.caltech.edu/16 fileserver tcp
spts:1024:65535 dpt:http state NEW reject-with icmp-port-unreachable
REJECT tcp -- caltech-net.caltech.edu/16 fileserver tcp
spts:1024:65535 dpt:http reject-with icmp-port-unreachable


Regards,

David Mathog

David Mathog wrote:

> At least partly this may be the WebDAV issue.

The other thing you want to do, in order to diagnose this, is to run
tcpdump on the server showing all packets to/from the client which is
trying to connect. I don't recall if tcpdump is before or after the
firewall - you may need to turn that off first. If the problem is
webDAV you'll see some packets from the client to port 80 on the host,
then nothing for a long time, then finally the SMB interaction.

Regards,

David Mathog

On Tue, 20 May 2008 09:32:56 -0700, David Mathog wrote:
> David Mathog wrote:
>
>> At least partly this may be the WebDAV issue.
>
> The other thing you want to do, in order to diagnose this, is to run
> tcpdump on the server showing all packets to/from the client which is
> trying to connect.

Using wireshark instead of tcpdump might be easier to use.

"dnoyeB" wrote in
news:PN6dnYjEnOeNfa_VnZ2dnUVZ_tXinZ2d@comcast.com:

> Are you connecting by IP address or hostname?

IP.

Frank

David Mathog wrote in news:g0us1j$fle$1
@naig.caltech.edu:

> At least partly this may be the WebDAV issue.

Hi David,

I disabled the WebClient service on the XP but it made no difference.

Frank

David Mathog wrote in news:g0uuft$h79$1
@naig.caltech.edu:

> The other thing you want to do, in order to diagnose this, is to run
> tcpdump on the server showing all packets to/from the client which is
> trying to connect.

Thanks,

I'll try this ASAP.


Frank

Bit Twister wrote in
news:slrng35vrq.nua.BitTwister@wm81.home.test:

> wireshark instead

OK. I'll try wireshark.

Thanks,


Frank

Frank Dreyfus wrote:
> David Mathog wrote in news:g0us1j$fle$1
> @naig.caltech.edu:
>
>> At least partly this may be the WebDAV issue.
>
> Hi David,
>
> I disabled the WebClient service on the XP but it made no difference.

Windows being windows, I wouldn't assume that just because you did
what should have turned it off, that it actually did turn off. In any
case...

What packets do you see going back and forth between the client
and server?
Anything useful in the Samba logs?
Try turning off the Samba machine's firewall and then try to connect.

Regards,

David Mathog

David Mathog wrote in news:g11fn3$4gc$1
@naig.caltech.edu:

>> I disabled the WebClient service on the XP but it made no difference.
>
> Windows being windows, I wouldn't assume that just because you did
> what should have turned it off, that it actually did turn off. In any
> case...
>
> What packets do you see going back and forth between the client
> and server?

Hi David,

Here's the data from wireshark. I'm not sure what the units of the
"Time" column are; but it seemed to take at least 30 seconds before the
first SMB packet. For the sake of brevity I'm only showing the summary
line for each packet; not the details. Here's the output:

No. Time Source Destination Protocol
Info
3367 100.303767 192.168.0.118 192.168.0.189 TCP
nssocketport > ncp [SYN] Seq=0 Win=65535 Len=0 MSS=1460
3702 103.316295 192.168.0.118 192.168.0.189 TCP
nssocketport > ncp [SYN] Seq=0 Win=65535 Len=0 MSS=1460
4001 109.331867 192.168.0.118 192.168.0.189 TCP
nssocketport > ncp [SYN] Seq=0 Win=65535 Len=0 MSS=1460
4652 121.363132 192.168.0.118 192.168.0.189 TCP
[TCP Port numbers reused] nssocketport > ncp [SYN] Seq=0 Win=65535 Len=0
MSS=1460
4918 124.425513 192.168.0.118 192.168.0.189 TCP
nssocketport > ncp [SYN] Seq=0 Win=65535 Len=0 MSS=1460
5310 130.441088 192.168.0.118 192.168.0.189 TCP
nssocketport > ncp [SYN] Seq=0 Win=65535 Len=0 MSS=1460
6146 142.472451 192.168.0.118 192.168.0.189 TCP
ecmport > ncp [SYN] Seq=0 Win=65535 Len=0 MSS=1460
6368 145.534739 192.168.0.118 192.168.0.189 TCP
ecmport > ncp [SYN] Seq=0 Win=65535 Len=0 MSS=1460
6989 151.550304 192.168.0.118 192.168.0.189 TCP
ecmport > ncp [SYN] Seq=0 Win=65535 Len=0 MSS=1460
8051 163.581523 192.168.0.118 192.168.0.189 TCP
[TCP Port numbers reused] ecmport > ncp [SYN] Seq=0 Win=65535 Len=0 MSS=
1460
8369 166.534569 192.168.0.118 192.168.0.189 TCP
ecmport > ncp [SYN] Seq=0 Win=65535 Len=0 MSS=1460
9256 172.550154 192.168.0.118 192.168.0.189 TCP
ecmport > ncp [SYN] Seq=0 Win=65535 Len=0 MSS=1460
10619 184.582201 192.168.0.118 192.168.0.189 SMB
Session Setup AndX Request, User: anonymous; Tree Connect AndX, Path:
\\192.168.0.189\IPC$
10620 184.585290 192.168.0.189 192.168.0.118 SMB
Session Setup AndX Response; Tree Connect AndX
10621 184.585519 192.168.0.118 192.168.0.189 SMB
Trans2 Request, GET_DFS_REFERRAL, File: \192.168.0.189\ct_backup
10622 184.586038 192.168.0.189 192.168.0.118 SMB
Trans2 Response, GET_DFS_REFERRAL, Error: STATUS_NOT_FOUND
10630 184.800057 192.168.0.118 192.168.0.189 TCP
boosterware > microsoft-ds [ACK] Seq=359 Ack=160 Win=64237 Len=0
12354 195.956290 192.168.0.118 192.168.0.189 SMB
Tree Disconnect Request
12355 195.956455 192.168.0.189 192.168.0.118 SMB
Tree Disconnect Response
12359 196.174966 192.168.0.118 192.168.0.189 TCP
boosterware > microsoft-ds [ACK] Seq=398 Ack=199 Win=64198 Len=0

> Anything useful in the Samba logs?

In my tests, the connection failed (probably timed out). There is
NOTHING in the Samba logs for the period of the test. I guess it never
connected.

On thing in the nmbd.log that may be of interest is this:

[2008/05/21 14:34:40, 0]
nmbd/nmbd_browsesync.c:find_domain_master_name_query_fa il(351)
find_domain_master_name_query_fail:
Unable to find the Domain Master Browser name HOMA<1b> for the
workgroup HOLO.
Unable to sync browse lists in this workgroup.

I don't know why I'm getting this but would it matter? Could it be that
when I try to connect Samba first looks for a DMB, that fails and the
whole thing times out?

> Try turning off the Samba machine's firewall and then try to connect.
I ran the test again with the firewall down and got similar results (I.E.
a long delay and no connection).

Do you think it might help to enable webdav on the server?

I don't think the WebClient service is running on the XP; but if you
question that fact, is there any way to test?

Thanks for your help,


Frank

Frank Dreyfus wrote:

> Here's the data from wireshark. I'm not sure what the units of the
> "Time" column are; but it seemed to take at least 30 seconds before the
> first SMB packet. For the sake of brevity I'm only showing the summary
> line for each packet; not the details. Here's the output:
>
> No. Time Source Destination Protocol
> Info
> 3367 100.303767 192.168.0.118 192.168.0.189 TCP
> nssocketport > ncp [SYN] Seq=0 Win=65535 Len=0 MSS=1460
> 3702 103.316295 192.168.0.118 192.168.0.189 TCP
> nssocketport > ncp [SYN] Seq=0 Win=65535 Len=0 MSS=1460
> 4001 109.331867 192.168.0.118 192.168.0.189 TCP
> nssocketport > ncp [SYN] Seq=0 Win=65535 Len=0 MSS=1460
> 4652 121.363132 192.168.0.118 192.168.0.189 TCP
> [TCP Port numbers reused] nssocketport > ncp [SYN] Seq=0 Win=65535 Len=0
> MSS=1460
> 4918 124.425513 192.168.0.118 192.168.0.189 TCP
> nssocketport > ncp [SYN] Seq=0 Win=65535 Len=0 MSS=1460
> 5310 130.441088 192.168.0.118 192.168.0.189 TCP
> nssocketport > ncp [SYN] Seq=0 Win=65535 Len=0 MSS=1460
> 6146 142.472451 192.168.0.118 192.168.0.189 TCP
> ecmport > ncp [SYN] Seq=0 Win=65535 Len=0 MSS=1460
> 6368 145.534739 192.168.0.118 192.168.0.189 TCP
> ecmport > ncp [SYN] Seq=0 Win=65535 Len=0 MSS=1460
> 6989 151.550304 192.168.0.118 192.168.0.189 TCP
> ecmport > ncp [SYN] Seq=0 Win=65535 Len=0 MSS=1460
> 8051 163.581523 192.168.0.118 192.168.0.189 TCP
> [TCP Port numbers reused] ecmport > ncp [SYN] Seq=0 Win=65535 Len=0 MSS=
> 1460
> 8369 166.534569 192.168.0.118 192.168.0.189 TCP
> ecmport > ncp [SYN] Seq=0 Win=65535 Len=0 MSS=1460
> 9256 172.550154 192.168.0.118 192.168.0.189 TCP
> ecmport > ncp [SYN] Seq=0 Win=65535 Len=0 MSS=1460

Is there a way to make wireshark emit port numbers instead of
translating them? If not, perhaps use tcpdump. I don't know what
ecmport, ncp, or nssocketport are. Digging around for likely suspects...

ncp = netware core protocol
nssocketport, not sure, maybe any unassigned port?
ecm is, hmm, something about factoring large prime numbers?

I think probably we can interpret both nssocketport and ecmport as
"randomly picked source sockets", and the key is that they are both
sending packets to ncp. If that really does mean Netware core protocol
perhaps you have Netware installed on the PC, and it's trying that
first? That's just a wild guess, I'd really like to see the port numbers.

Also, this is just a mount of an SMB share, rather than a full domain
login, right?

Regards,

David Mathog

David Mathog wrote in
news:g143jn$sp0$1@naig.caltech.edu:

> Is there a way to make wireshark emit port numbers instead of
> translating them? If not, perhaps use tcpdump. I don't know what
> ecmport, ncp, or nssocketport are. Digging around for likely
> suspects...
>
> ncp = netware core protocol
> nssocketport, not sure, maybe any unassigned port?
> ecm is, hmm, something about factoring large prime numbers?
>

This was my 1st time using wireshark; but I'll look into it and see what
I can do. I'm pretty sure the port numbers are in the details which I
omitted b/c they are quite voluminous.

> I think probably we can interpret both nssocketport and ecmport as
> "randomly picked source sockets", and the key is that they are both
> sending packets to ncp. If that really does mean Netware core
> protocol perhaps you have Netware installed on the PC, and it's trying
> that first? That's just a wild guess, I'd really like to see the port
> numbers.

Yes, we have a Netware server. However, the results I posted were
filtered for traffic between the client (192.168.0.118) and the
linux/samba server (192.168.0.189).

>
> Also, this is just a mount of an SMB share, rather than a full domain
> login, right?

I'm not sure what you mean be a full domain login. I'm trying to browse
one specific share. It's a folder on the server: /home/chris/backup.

Thanks,


Frank

David Mathog wrote in news:g143jn$sp0$1
@naig.caltech.edu:

> perhaps you have Netware installed on the PC

Hi David,

Just a bit more info.

I temporarily removed the Netware Client from the LAN connection on the
XP box (there is no Netware client on the Samba server).

It made no difference.

I know that's not the whole story but just wanted to pass that info
along.

Thanks,


Frank

I sent you a log of a complete tcpdump via email. It was too big to
post here. If you don't get it let me know.

Regards,

David Mathog

David Mathog wrote in news:g14tli$f97$1
@naig.caltech.edu:

> I sent you a log of a complete tcpdump via email. It was too big to
> post here. If you don't get it let me know.

Hi David,

I'm sorry, that's a phony email address.

Would you be able to ftp it here: 69.177.95.51 Your name and p/w is david
and david.

I've just enabled the ftp server and it seems very slow but works.

Thanks,


Frank

Frank Dreyfus wrote:

> I'm sorry, that's a phony email address.

Figured that out from the bounce :-).

>
> Would you be able to ftp it here: 69.177.95.51

Uploaded.

Hope it helps,

David Mathog

Would like to most my experience with this issue.

I would notice the slow-down when right-clicking on a share name (my home share) when browsing the Samba server (connecting to \\, like if I wanted to bring up properties for the share.

Wireshark showed a port 80 connection as soon as I right-clicked, and a list of GET_DFS_REFERRAL/STATUS_NOT_FOUND errors. It's tough to tell which error packet is related to the slow-down, but some of the packets were delayed until the right-click context menu actually appeared.

I turned off iptables to un-filter port 80, which just resulted in several RST, ACK instead of the initial ICMP rejection notice.

After reading this post, I turned off the Web Client service in Windows XP SP3 (Control Panel->Administrative Tools->Services) and eureka, no more slow down.

Looks like Windows tries to use WebDAV when browsing shares. Damn you Microsoft, damn you.