Interop Issue: SMB2+ async replies, and the kernel, Samba side fix enclosed.

Shirish Pargaonkar shirishpargaonkar at
Sat Feb 27 13:50:08 UTC 2016

Pavel, briefly tested this, it looks good. No error (messages) logged.

Tested-by: Shirish Pargaonkar <shirishpargaonkar at>

On Sat, Feb 27, 2016 at 3:31 AM, Pavel Shilovsky <piastryyy at> wrote:
> 2016-02-27 12:11 GMT+03:00 Pavel Shilovsky <pshilovsky at>:
>> 2016-02-23 15:55 GMT+03:00 Ira Cooper <ira at>:
>>> If the server sends an interim response, then the real response, the real
>>> response, is handled by standard_receive3() in the kernel, instead of the
>>> proper function, and this causes a disconnect.  If there isn't a
>>> disconnect, I believe the reply will just be discarded if I understand the
>>> code correctly.  (That is a big if here ;) )
>>> I've written a patch for Samba to stop sending interim replies on
>>> and SMB2_WRITE, when non-compounded to stop the impact of this issue.  We
>>> may want to add SMB2_CREATE to the list of ops we don't send async replies
>>> for non-compounded, but I'm not sold either way, I know we CAN go async
>>> there!  I want some opinions here.
>>> This is not hidden behind a flag because compatibility issues that don't
>>> impact protocol correctness usually aren't.
>>> Setting req->async_te = talloc_new(NULL); is just ugly, though it works.
>>> If you have a cleaner approach, I welcome it.
>>> I request you please ASK me before pushing this one, yes, that means you
>>> jra!
>>> For those interested in reproduction: I'd suggest using a server that's
>>> rebuilt with a lower timeout set in smb2_read.c, though we've hit it with
>>> vfs_glusterfs straight up, in our testing.
>>> Thanks,
>>> -Ira / ira@(||
>> Thank you for catching this!
>> It is the issue in the kernel client - a check for interim responses is
>> missed for SMB2_READ command. I created a patch that should fix the problem.
>> Could you please test it?
>> --
>> Best regards,
>> Pavel Shilovsky
> CC'ing @samba-technical.
> Sorry for the spam.
> --
> Best regards,
> Pavel Shilovsky

More information about the samba-technical mailing list