Sidebar to Apple OS X SMB issues across VPN

Christopher R. Hertel crh at
Mon Oct 24 20:56:49 GMT 2005


The continuation messages occur whenever the SMB message is larger than 
the MTU on the link.  It's the TCP/IP stack that breaks the large SMB down 
into smaller chunks for transmission.

The side effect is that the SMB layer believes (rightly) that it has sent
the entire message and is now free to go about other business, letting
TCP/IP deal with the messy issue of delivery and reconstruction.

I am running a newer version of Ethereal on my office PC, and I've noticed
something that I missed when I was working at home.  Going back to packet
345 in that capture.cap we're using:

- In the NetBIOS Session Service Header (the NBT Header) the length of the
  message is given as 16404 bytes, more than 10 times the default MTU on a 
  typical link.  The actual frames max out at only 1434 bytes.

- The message size of 16404 is also more than twice the TCP window size 

- There are a lot of incorrect checksums in the sequence starting at
  packet 345.  I think Ronnie Sahlberg explained this to me once but I 
  can't remember why this happens.  It's a bug somewhere but not, it 
  seems, a critical one.

- There are a handful of duplicate ACKs in this exchange, and two TCP 
  retransmissions.  That suggests some sort of packet loss or congestion
  and explains why this single message takes more than 1.6 seconds to 
  reach its destination.

Regarding the overlapping of requests, clients can multiplex the
communications of multiple processes or threads within the same TCP
connection.  Windows does this routinely, since it generally opens only
one TCP connection, from within the kernel, per client/server pair.  The 
Programs in the Samba suite tend to use separate TCP connections since 
they're all running in different contexts.

The PID and MID fields in the header let the server know which client
context is making the request, so the server can manage the threads and
keep the contexts straight.  I don't see the server's NegProt response in
this trace, so I can't tell what the server is setting as a MaxMpxCount.  
In theory, you could have as many as MaxMpxCount different requests
outstanding at any one time.

Chris -)-----

On Mon, Oct 24, 2005 at 03:02:31PM -0400, David Collier-Brown wrote:
>  I find I have a problem with overlapped requests and 
> NBSS Continuation messages.
>  To disambiguate the latter,
> is there a specific set of operations which cause them?
> In the sample I have it's FIND_FIRST2, FIND_NEXT2,
> Read and Create/Write.  Is this an exhaustive list? If
> not, is there a way of enumerating the continuable 
> SMBs?
> --dave
> David Collier-Brown wrote:
> > GPL is fine, it's a nawk script (:-))
> > I'm code-reviewing it today, anyone a nawk/gawk
> >person to review it on Linux, etc?
> >
> >--dave
> >
> >Jeremy Allison wrote:
> >
> >>On Sun, Oct 23, 2005 at 04:31:25PM -0400, David Collier-Brown wrote:
> >>
> >>>I did a quickie SMB profiler that works on any capture
> >>>file tethereal can read.
> >>>Running it on this server gave me the following breakdown:
> >>>
> >>>This was a side-effect of my timing FIND_FIRST2 in large directories,
> >>>which seems to be slower that expected on OS X: we're going
> >>>to compare it to Linux next.
> >>>
> >>>If this is a useful tool for the team, I'll happily donate it.
> >>
> >>
> >>
> >>I'd love to have it, so long as it's GPL, not under that Sun
> >>crappy license :-). (I had arguments with Sun engineers and
> >>execs at the NAS conference this week due to the license being
> >>explicitly GPL incompatible.... :-).
> >>
> >>Thanks,
> >>
> >>Jeremy.
> >>
> >
> -- 
> David Collier-Brown,      | Always do right. This will gratify
> Sun Microsystems, Toronto | some people and astonish the rest
> davecb at     |                      -- Mark Twain
> (416) 263-5733 (x65733)   |

"Implementing CIFS - the Common Internet FileSystem" ISBN: 013047116X
Samba Team --     -)-----   Christopher R. Hertel
jCIFS Team --   -)-----   ubiqx development, uninq.
ubiqx Team --     -)-----   crh at
OnLineBook --    -)-----   crh at

More information about the samba-technical mailing list