smbclient -M : big delays (fwd)

[David Lee]

Are we alone with this problem of 15-second "smbclient -M"?

Has anyone else seen it?

Can anyone confirm it?  (Or confirm that it is lightning fast for them,
so it must be our problem?)

Our clients are W2K.  The "About Windows" says:
   Version 5.0 (Build 2195: Service Pack 1)

Our Samba servers (from which we run "smbclient -M") are Solaris 2.7 and
2.8, running a variety of Samba versions (both 2.0.x and 2.2.x).  But all
consistently give this delay (a 5-second delay at PC-client-end responding
to each of the three "SMBsend*" packets from the Solaris/samba server).

We're at a complete loss on this one...


-- 


:  David Lee                                I.T. Service          :
:  Systems Programmer                       Computer Centre       :
:                                           University of Durham  :
:  http://www.dur.ac.uk/t.d.lee/            South Road            :
:                                           Durham                :
:  Phone: +44 191 374 2882                  U.K.                  :

---------- Forwarded message ----------
Date: Tue, 2 Apr 2002 12:49:37 +0100 (BST)
From: David Lee <t.d.lee at durham.ac.uk>
To: samba-technical at lists.samba.org
Subject: smbclient -M : big delays

Back in the days of 2.2.1a, I noticed a problem using "smbclient -M" to
send WinPopup messages from a server (Solaris 2.x) to a client (W2K).  But
I was unable to pursue it at the time.

I have just started looking at this area again, using Samba 2.2.3a, and
the problem still seems to be present.

Briefly, the symptom is a long delay (pushing 15 seconds) before the
message is displayed on the client. 

Looking more deeply (using "snoop" on the UNIX box to capture the network
traffic), what is seen is: 

1. rapid exchange of about 6 packets as the session is established (fine).

2. UNIX (smbclient) sends "SMBsendstrt" quickly.
   -- total elapsed time so far about 0.3 seconds (fine)

3. big delay (~ 5 seconds) before client (W2k) returns the SMBsendstrt
   acknowledgement (problem).

4. rapid UNIX turnaround to send "SMBsendtxt" (fine).

5. big delay before client (W2K) acknowledges "SMBsendtxt" (problem)

6. rapid UNIX turnaround to send "SMBsendend" (fine)

7. big delay before client (W2K) acknowledges "SMBsendend" (problem).


At first sight, the problem appears to lie at the PC/client end, waiting
nearly five seconds before acknowledging each of the "SMBsend*" that had
come from the UNIX/server. 

Might this be this a known PC/client/W2K problem?  (Testing with non-W2K
client-types would be trickly, but possibly do-able if necessary.)

Or is it actually a Samba problem?  (For instance, are the "SMBsend*" 
packets improperly constructed (e.g. (speculative) not pushed), leading
the PC/client to believe that the packet is, for instance, incomplete.)

I've got no experience of programming at the SMB level, so am somewhat
lost.

But if anyone can reproduce it, and if anyone can help pursue it, I can
provide the UNIX "snoop" output.

-- 

:  David Lee                                I.T. Service          :
:  Systems Programmer                       Computer Centre       :
:                                           University of Durham  :
:  http://www.dur.ac.uk/t.d.lee/            South Road            :
:                                           Durham                :
:  Phone: +44 191 374 2882                  U.K.                  :