My WinXP clients are able to map a network drive on my samba server.
However, it takes 30 seconds to do so, and accessing the contents of the
shared drive is also quite slow.
Linux (smbclient) and Windows 2000 clients are able to map the share
instantly, and access files without delay.
I am using Linux 2.4.5, with samba 2.2.3a compiled from source on the
server. The delay is consistent at 30 seconds, and occurs just after
the authentication protocol is negotiated. Authentication succeeds
after a 30 second delay.
I use this command line on the windows clients (both 2000 and XP use the
same command):
net use * \\demeter\jamesn /user:jamesn
The NetBIOS name Demeter resolves correctly and instantly to
192.168.0.77 on any machine (I've added a static mapping in the WINS
server). The negotiated protocol is NT LM 0.12 - I've tried restricting
this to LANMAN1, but the 30 second delay still occurs at the same spot.
I've included my smb.conf below, as well as part of a level 3 log
showing when the timeout occurs.
I would appreciate any help that you can give me on this. I have no
idea what changed from Windows 2000 to Windows XP to cause this problem.
Smb.conf:
[global]
log file = /usr/local/samba/var/log.smbd
log level = 10
workgroup = ARIES
interfaces = 192.168.0.0/24 lo
bind interfaces only = Yes
encrypt passwords = Yes
socket address = 192.168.0.77
guest account security = user
wins server = 192.168.0.167
name resolve order = wins lmhosts hosts bcast
[homes]
read only = No
hide dot files = No
create mask = 0644
invalid users = root
Level 3 log:
[2002/04/29 13:37:55, 3] smbd/negprot.c:reply_negprot(348)
Requested protocol [PC NETWORK PROGRAM 1.0]
[2002/04/29 13:37:55, 3] smbd/negprot.c:reply_negprot(348)
Requested protocol [LANMAN1.0]
[2002/04/29 13:37:55, 3] smbd/negprot.c:reply_negprot(348)
Requested protocol [Windows for Workgroups 3.1a]
[2002/04/29 13:37:55, 3] smbd/negprot.c:reply_negprot(348)
Requested protocol [LM1.2X002]
[2002/04/29 13:37:55, 3] smbd/negprot.c:reply_negprot(348)
Requested protocol [LANMAN2.1]
[2002/04/29 13:37:55, 3] smbd/negprot.c:reply_negprot(348)
Requested protocol [NT LM 0.12]
[2002/04/29 13:37:55, 3] smbd/negprot.c:reply_negprot(432)
Selected protocol NT LM 0.12
[2002/04/29 13:38:25, 3] smbd/process.c:process_smb(860)
Transaction 2 of length 197
[2002/04/29 13:38:25, 3] smbd/process.c:switch_message(667)
switch message SMBsesssetupX (pid 31398)
[2002/04/29 13:38:25, 3] smbd/sec_ctx.c:set_sec_ctx(314)
setting sec ctx (0, 0) - sec_ctx_stack_ndx = 0
[2002/04/29 13:38:25, 3] smbd/reply.c:reply_sesssetup_and_X(848)
Domain=[ARIES] NativeOS=[Windows 2002 2600] NativeLanMan=[Windows
2002 5.1]
[2002/04/29 13:38:25, 3] smbd/reply.c:reply_sesssetup_and_X(858)
sesssetupX:name=[jamesn]
Would you consider running tcpdump on the linux server to watch the interaction? I haven't noticed a slow access problem with XPpro, but I don't use authenticatation (security=share and guest=ftp and guest ok = yes) Joel On Mon, Apr 29, 2002 at 04:30:00PM -0500, James Northcott wrote:> My WinXP clients are able to map a network drive on my samba server. > However, it takes 30 seconds to do so, and accessing the contents of the > shared drive is also quite slow. > > Linux (smbclient) and Windows 2000 clients are able to map the share > instantly, and access files without delay. > > I am using Linux 2.4.5, with samba 2.2.3a compiled from source on the > server. The delay is consistent at 30 seconds, and occurs just after > the authentication protocol is negotiated. Authentication succeeds > after a 30 second delay. > > I use this command line on the windows clients (both 2000 and XP use the > same command): > > net use * \\demeter\jamesn /user:jamesn > > The NetBIOS name Demeter resolves correctly and instantly to > 192.168.0.77 on any machine (I've added a static mapping in the WINS > server). The negotiated protocol is NT LM 0.12 - I've tried restricting > this to LANMAN1, but the 30 second delay still occurs at the same spot. > > I've included my smb.conf below, as well as part of a level 3 log > showing when the timeout occurs. > > I would appreciate any help that you can give me on this. I have no > idea what changed from Windows 2000 to Windows XP to cause this problem. > > Smb.conf: > > [global] > log file = /usr/local/samba/var/log.smbd > log level = 10 > workgroup = ARIES > interfaces = 192.168.0.0/24 lo > bind interfaces only = Yes > encrypt passwords = Yes > socket address = 192.168.0.77 > guest account > security = user > wins server = 192.168.0.167 > name resolve order = wins lmhosts hosts bcast > > [homes] > read only = No > hide dot files = No > create mask = 0644 > invalid users = root > > Level 3 log: > > [2002/04/29 13:37:55, 3] smbd/negprot.c:reply_negprot(348) > Requested protocol [PC NETWORK PROGRAM 1.0] > [2002/04/29 13:37:55, 3] smbd/negprot.c:reply_negprot(348) > Requested protocol [LANMAN1.0] > [2002/04/29 13:37:55, 3] smbd/negprot.c:reply_negprot(348) > Requested protocol [Windows for Workgroups 3.1a] > [2002/04/29 13:37:55, 3] smbd/negprot.c:reply_negprot(348) > Requested protocol [LM1.2X002] > [2002/04/29 13:37:55, 3] smbd/negprot.c:reply_negprot(348) > Requested protocol [LANMAN2.1] > [2002/04/29 13:37:55, 3] smbd/negprot.c:reply_negprot(348) > Requested protocol [NT LM 0.12] > [2002/04/29 13:37:55, 3] smbd/negprot.c:reply_negprot(432) > Selected protocol NT LM 0.12 > [2002/04/29 13:38:25, 3] smbd/process.c:process_smb(860) > Transaction 2 of length 197 > [2002/04/29 13:38:25, 3] smbd/process.c:switch_message(667) > switch message SMBsesssetupX (pid 31398) > [2002/04/29 13:38:25, 3] smbd/sec_ctx.c:set_sec_ctx(314) > setting sec ctx (0, 0) - sec_ctx_stack_ndx = 0 > [2002/04/29 13:38:25, 3] smbd/reply.c:reply_sesssetup_and_X(848) > Domain=[ARIES] NativeOS=[Windows 2002 2600] NativeLanMan=[Windows > 2002 5.1] > [2002/04/29 13:38:25, 3] smbd/reply.c:reply_sesssetup_and_X(858) > sesssetupX:name=[jamesn] > > > -- > To unsubscribe from this list go to the following URL and read the > instructions: http://lists.samba.org/mailman/listinfo/samba
>>My WinXP clients are able to map a network drive on my samba server. >>However, it takes 30 seconds to do so>I don't recognize the problem, offhand, but I'd try cranking up the log >level to 10 and try again. The reason is that there is a 30 seconddelay>between the end of the protocol level negotiation and the beginning ofthe>first SMB transaction. By cranking up the log level to the maximum,you>might find out what's going on during those 30 seconds...OK, I've included a level 10 log excerpt. It's not very exciting - the Samba server transmits, and then XP waits 30 seconds before replying.>Also, you might want to check the "nmbd" log file as well - there maybe>something going on there. Some people were experiencing DNSreverse-lookup>timeouts, and even though your smb.conf settings don't look like theywould>cause this issue to occur, your description of the symptom soundssimilar. I'm not using nmbd. I don't require browsing to work on this server, and I don't require broadcast name resolution for this to work since I've added a static mapping in my WINS server. Just for fun, I turned on nmbd on my samba server - no dice, and nothing going on in the nmbd log. As near as I can tell, it's not even looking up the name via broadcast.>Hope that helps...Level 10 log (I've left some blank lines to show where the delay occurs): [2002/04/29 14:50:11, 5] lib/util.c:show_msg(281) smb_tid=0 smb_pid=65279 smb_uid=0 smb_mid=0 smt_wct=17 [2002/04/29 14:50:11, 5] lib/util.c:show_msg(286) smb_vwv[0]=5 (0x5) [2002/04/29 14:50:11, 5] lib/util.c:show_msg(286) smb_vwv[1]=12803 (0x3203) [2002/04/29 14:50:11, 5] lib/util.c:show_msg(286) smb_vwv[2]=256 (0x100) [2002/04/29 14:50:11, 5] lib/util.c:show_msg(286) smb_vwv[3]=65280 (0xFF00) [2002/04/29 14:50:11, 5] lib/util.c:show_msg(286) smb_vwv[4]=255 (0xFF) [2002/04/29 14:50:11, 5] lib/util.c:show_msg(286) smb_vwv[5]=0 (0x0) [2002/04/29 14:50:11, 5] lib/util.c:show_msg(286) smb_vwv[6]=256 (0x100) [2002/04/29 14:50:11, 5] lib/util.c:show_msg(286) smb_vwv[7]=42240 (0xA500) [2002/04/29 14:50:11, 5] lib/util.c:show_msg(286) smb_vwv[8]=15 (0xF) [2002/04/29 14:50:11, 5] lib/util.c:show_msg(286) smb_vwv[9]=63744 (0xF900) [2002/04/29 14:50:11, 5] lib/util.c:show_msg(286) smb_vwv[10]=3 (0x3) [2002/04/29 14:50:11, 5] lib/util.c:show_msg(286) smb_vwv[11]=32768 (0x8000) [2002/04/29 14:50:11, 5] lib/util.c:show_msg(286) smb_vwv[12]=26843 (0x68DB) [2002/04/29 14:50:11, 5] lib/util.c:show_msg(286) smb_vwv[13]=46866 (0xB712) [2002/04/29 14:50:11, 5] lib/util.c:show_msg(286) smb_vwv[14]=49647 (0xC1EF) [2002/04/29 14:50:11, 5] lib/util.c:show_msg(286) smb_vwv[15]=11265 (0x2C01) [2002/04/29 14:50:11, 5] lib/util.c:show_msg(286) smb_vwv[16]=2049 (0x801) [2002/04/29 14:50:11, 5] lib/util.c:show_msg(291) smb_bcc=14 [2002/04/29 14:50:11, 10] lib/util.c:dump_data(1484) [000] 76 FF A5 D2 B9 6B 08 0E 41 52 49 45 53 00 v....k.. ARIES. [2002/04/29 14:50:11, 6] lib/util_sock.c:write_socket(518) write_socket(13,87) [2002/04/29 14:50:11, 6] lib/util_sock.c:write_socket(521) write_socket(13,87) wrote 87 [2002/04/29 14:50:41, 10] lib/util_sock.c:read_smb_length_return_keepalive(560) got smb length of 193 [2002/04/29 14:50:41, 6] smbd/process.c:process_smb(859) got message type 0x0 of len 0xc1 [2002/04/29 14:50:41, 3] smbd/process.c:process_smb(860) Transaction 2 of length 197 [2002/04/29 14:50:41, 5] lib/util.c:show_msg(275) size=193 smb_com=0x73 smb_rcls=0 smb_reh=0 smb_err=0 smb_flg=24 smb_flg2=18439 [2002/04/29 14:50:41, 5] lib/util.c:show_msg(281) smb_tid=0 smb_pid=65279 smb_uid=0 smb_mid=64 smt_wct=13 [2002/04/29 14:50:41, 5] lib/util.c:show_msg(286) smb_vwv[0]=117 (0x75) [2002/04/29 14:50:41, 5] lib/util.c:show_msg(286) smb_vwv[1]=158 (0x9E) [2002/04/29 14:50:41, 5] lib/util.c:show_msg(286) smb_vwv[2]=65535 (0xFFFF) [2002/04/29 14:50:41, 5] lib/util.c:show_msg(286) smb_vwv[3]=50 (0x32) [2002/04/29 14:50:41, 5] lib/util.c:show_msg(286) smb_vwv[4]=0 (0x0) [2002/04/29 14:50:41, 5] lib/util.c:show_msg(286) smb_vwv[5]=4005 (0xFA5) [2002/04/29 14:50:41, 5] lib/util.c:show_msg(286) smb_vwv[6]=0 (0x0) [2002/04/29 14:50:41, 5] lib/util.c:show_msg(286) smb_vwv[7]=24 (0x18) [2002/04/29 14:50:41, 5] lib/util.c:show_msg(286) smb_vwv[8]=24 (0x18) [2002/04/29 14:50:41, 5] lib/util.c:show_msg(286) smb_vwv[9]=0 (0x0) [2002/04/29 14:50:41, 5] lib/util.c:show_msg(286) smb_vwv[10]=0 (0x0) [2002/04/29 14:50:41, 5] lib/util.c:show_msg(286) smb_vwv[11]=212 (0xD4) [2002/04/29 14:50:41, 5] lib/util.c:show_msg(286) smb_vwv[12]=0 (0x0)
>Would you consider running tcpdump on the linux server to watch the >interaction? I haven't noticed a slow access problem with XPpro, but I >don't use authenticatation (security=share and guest=ftp and guest ok yes) >JoelOK, here's the output from tcpdump on the samba server. I'm having trouble with the smb-modified version, so this is just regular tcpdump. 07:56:21.841655 192.168.0.6.2062 > 192.168.0.77.netbios-ssn: S 2297483761:2297483761(0) win 64240 <mss 1460,nop,nop,sackOK> (DF) 07:56:21.841700 192.168.0.77.netbios-ssn > 192.168.0.6.2062: S 2739553887:2739553887(0) ack 2297483762 win 3840 <mss 960,nop,nop,sackOK> (DF) 07:56:21.883584 192.168.0.6.2062 > 192.168.0.77.netbios-ssn: P 1:73(72) ack 1 win 64320 (DF) 07:56:21.883616 192.168.0.77.netbios-ssn > 192.168.0.6.2062: . ack 73 win 3840 (DF) 07:56:21.887651 192.168.0.77.netbios-ssn > 192.168.0.6.2062: P 1:5(4) ack 73 win 3840 (DF) 07:56:21.931247 192.168.0.6.2062 > 192.168.0.77.netbios-ssn: P 73:210(137) ack 5 win 64316 (DF) 07:56:21.933092 192.168.0.77.netbios-ssn > 192.168.0.6.2062: P 5:92(87) ack 210 win 4824 (DF) 07:56:22.130539 192.168.0.6.2062 > 192.168.0.77.netbios-ssn: . ack 92 win 64229 (DF) 07:56:52.015829 192.168.0.6.2062 > 192.168.0.77.netbios-ssn: P 210:407(197) ack 92 win 64229 (DF) 07:56:52.024690 192.168.0.77.netbios-ssn > 192.168.0.6.2062: P 92:181(89) ack 407 win 5896 (DF) 07:56:52.203079 192.168.0.6.2062 > 192.168.0.77.netbios-ssn: . ack 181 win 64140 (DF) I just don't see anything funny there. I'm going to try running tcpdump on my WinXP client and see what happens...>On Mon, Apr 29, 2002 at 04:30:00PM -0500, James Northcott wrote: >> My WinXP clients are able to map a network drive on my samba server. >> However, it takes 30 seconds to do so, and accessing the contents ofthe>> shared drive is also quite slow. >> >> Linux (smbclient) and Windows 2000 clients are able to map the share >> instantly, and access files without delay. >>