[Samba] multiple smb commands (some non AndX) in one packet

[Shirish Pargaonkar]

No, I am talking about multiple smb commands in the same tcp frame and
not necessarily andx commands.
I see a tcp frame with multiple smb commands going over to Windows XP
server and the server either responds to the first command and ignores rest
or does not respond and cifs client reconnects thinking server is not
responding.
I see the same problem with samba server (cifs client reconnecting after logging
server does not respond or No response for/to cmd), just that I have not been
able to capture the wireshark trace successfully (unpredictable timing and
too much traffic, wireshark dropping packets etc.).

cifs client does not do this (bundling multiple smb commands) conciously,
I think tcp does club them together and if tcp is doing that, I do not know why
and how to prevent it and if it can't be prevented, would be nice if
samba server
can tackle them.


On 6/4/08, Volker Lendecke <Volker.Lendecke at sernet.de> wrote:
> On Wed, Jun 04, 2008 at 11:42:30AM -0700, Jeremy Allison wrote:
> > On Wed, Jun 04, 2008 at 01:36:20PM -0500, Shirish Pargaonkar wrote:
> > > Does samba server handle multiple smb commands (not necessarily andx commands)
> > > within one packet?  If a client were to send commands such as 0x2f, 0x32, 0x32
> > > in one packet instead of three separate packets, does samba server
> > > handle it i.e.
> > > respond to each of the three requests?
> >
> > Yes, we should do that. Of course there are earlier
> > bugs in the implementation but I believe as of our
> > latest code (3.0.30 and 3.2rc's) we handle this
> > correctly.
>
> Isn't it that we only have to take special care of the andX
> type requests? For the other ones we should not even notice
> that there are multiple requests in a TCP packet. 0x2f is
> writeX, this might require special handling, but the fact
> that 0x32 (trans2) is followed by something else in the same
> frame shouldn't be noticed by smbd at all.
>
> Or are you doing something special magic to wrap these into
> the same netbios-level message (no idea how this should
> work...)? :-)
>
> Volker
>
>