[cifs-protocol] [EXTERNAL] Seeking clarification of SMB3 async behavior in a compound request. - TrackingID#2209220040008649

[Jeff McCashland (He/him)]

Hi Jeremy, 

Please find attached t_cmd.txt that can be renamed to t.cmd. 

To collect traces:
	1. From an elevated command prompt on the Server, execute the command 't.cmd srvon'
	2. Start network traces (also on the server)
	3. Repro the issue
	4. Stop network traces
	5. From the elevated command prompt on the Server, execute the command 't.cmd srvoff'. This will create a t.cab file with a timestamped name.
	6. Please upload the .cab file and the network traces to the DTM workspace (credentials below)

Please note which frames in the network trace are significant. 

Workspace credentials: Log in as 2209220040008649_jeremy at dtmxfer.onmicrosoft.com
1-Time: 57(KI_9n

Workspace link: https://support.microsoft.com/files?workspace=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiJ9.eyJ3c2lkIjoiYjRiYzNkOTUtZmE1Ni00ZWFkLWI2Y2QtZWU2NDRkNDgwZmFjIiwic3IiOiIyMjA5MjIwMDQwMDA4NjQ5IiwiYXBwaWQiOiI0ZTc2ODkxZC04NDUwLTRlNWUtYmUzOC1lYTNiZDZlZjIxZTUiLCJzdiI6InYxIiwicnMiOiJFeHRlcm5hbCIsInd0aWQiOiJmNjk1NzIzNy01YWM5LTQ2MmEtOGY0NC04ZjViYjI4YTNlNDAiLCJpc3MiOiJodHRwczovL2FwaS5kdG1uZWJ1bGEubWljcm9zb2Z0LmNvbSIsImF1ZCI6Imh0dHA6Ly9zbWMiLCJleHAiOjE2NzE3MjcyMDcsIm5iZiI6MTY2Mzk1MTIwN30.TZ_XsbFp3URCzFj2PtvBRC9t_jXuNO2e3NOuWx8MmPrxi3Esw8nCO9r35iTPshi_CbOIpPbHUtixKjvnTBsCnbyBr5uqg_YDmTWbeNfXLSkytbnTEPv3BjzaoghZHPpCDQPvSp0wxTScCRZ0zgeyCJXZESaCsbMsSXfBtX_DpeNpkXSRQ_BIHZ71-1xOGdlbnr35D4reDOJMGU1paKjlmuYTa7IcXNm5Coq5lG7xSwC2BxBbuHsAG8qcjpqbdDjxwOqJDWCTeBVPzoWD5e79rWlx9Nbl7WRRfOpI7U2lyqzVsLIIUGTU7HMbKr3m4FbUjFBoXElQjVKio1-VrXCMZA&wid=b4bc3d95-fa56-4ead-b6cd-ee644d480fac

Best regards,
Jeff McCashland (He/him) | Senior Escalation Engineer | Microsoft Protocol Open Specifications Team 
Phone: +1 (425) 703-8300 x38300 | Hours: 9am-5pm | Time zone: (UTC-08:00) Pacific Time (US and Canada)
Local country phone number found here: http://support.microsoft.com/globalenglish | Extension 1138300

-----Original Message-----
From: Jeff McCashland (He/him) 
Sent: Thursday, September 22, 2022 7:19 PM
To: Jeremy Allison <jra at samba.org>
Cc: cifs-protocol at lists.samba.org; metze <metze at samba.org>; Microsoft Support <supportmail at microsoft.com>
Subject: RE: [EXTERNAL] Seeking clarification of SMB3 async behavior in a compound request. - TrackingID#2209220040008649

[Kristian to BCC]

Hi Jeremy,

I will be assisting you with this issue. Tomorrow I will send instructions for collecting and uploading traces. 

Best regards,
Jeff McCashland (He/him) | Senior Escalation Engineer | Microsoft Protocol Open Specifications Team
Phone: +1 (425) 703-8300 x38300 | Hours: 9am-5pm | Time zone: (UTC-08:00) Pacific Time (US and Canada) Local country phone number found here: http://support.microsoft.com/globalenglish | Extension 1138300

-----Original Message-----
From: Kristian Smith <Kristian.Smith at microsoft.com>
Sent: Thursday, September 22, 2022 4:31 PM
To: Jeremy Allison <jra at samba.org>
Cc: cifs-protocol at lists.samba.org; metze <metze at samba.org>; Microsoft Support <supportmail at microsoft.com>
Subject: RE: [EXTERNAL] Seeking clarification of SMB3 async behavior in a compound request. - TrackingID#2209220040008649

[DocHelp to Bcc]

Hi Jeremy,

Thank you for your request. The case number 2209220040008649 has been created for this inquiry. One of our team members will follow-up with you soon.

Regards,
Kristian

Kristian Smith
Support Escalation Engineer
Windows Open Spec Protocols
Office: (425) 421-4442
kristian.smith at microsoft.com 


-----Original Message-----
From: Jeremy Allison <jra at samba.org>
Sent: Thursday, September 22, 2022 4:02 PM
To: Interoperability Documentation Help <dochelp at microsoft.com>
Cc: jra at samba.org; cifs-protocol at lists.samba.org; metze <metze at samba.org>
Subject: [EXTERNAL] Seeking clarification of SMB3 async behavior in a compound request.

Hi Dochelp,

I'm seeking clarify on the behavior of compound requests going async in SMB3.

MS-SMB2 states in:

-------------------------------------------------------
3.3.5.2.7.2 Handling Compounded Related Requests

When an operation requires asynchronous processing, all the subsequent operations MUST also be processed asynchronously. The server MUST send an interim response for all such operations as specified in section 3.3.4.2.
-------------------------------------------------------

But this doesn't appear to be the case against Windows 2022.

I have a set of tests that do the following to force asynchronous operation in compound requests against Windows 2022 (thanks to Metze for the ideas for these).

Test #1

     Opendir foo <- returns foo-handle
     notify on foo-handle
     create foo/bar
     notify recv
     delete foo/bar
Compound --------------
      notify on foo-handle
      close (compound handle)
      --------------

When the server sees the compound request starting with the notify in this test it should have a pending FILE_DELETED notify return queued up and ready to return for the compound notify, so this test should not need to go async at all.

However, Windows 2022 returns NT_STATUS_INTERNAL_ERROR for the compound notify request.

Test #2

     Opendir foo <- returns foo-handle
     notify on foo-handle
     create foo/bar
     notify recv
     delete foo/bar
Compound --------------
      getinfo foo-handle
      notify (compound handle)
      close (compound handle)
      --------------

This test is the same as test #1, with
the addition of the getinfo foo-handle
in the compound to determine how Windows behaves when a request that might go async is in the middle of the compound stream.

When the server sees the compound request starting with the notify in this test it should have a pending DELETE-FILE notify return queued up and ready to return for the compound notify, so this test should not need to go async at all.

However, Windows 2022 returns NT_STATUS_INTERNAL_ERROR for the compound notify request.

Test #3

     Opendir foo <- returns foo-handle
     notify on foo-handle
     create foo/bar
     notify recv
Compound --------------
      notify foo-handle
      close (compound handle)
      --------------

When the server sees the compound request starting with the notify in this test it should have no pending requests to return, and so the compound notify should be forced to go async.

However, Windows 2022 returns NT_STATUS_INTERNAL_ERROR for the compound notify request.

Test #4

     Opendir foo <- returns foo-handle
     notify on foo-handle
     notify foo
     create foo/bar
     notify recv
Compound --------------
      getinfo foo-handle
      notify (compound handle)
      close (compound handle)
      --------------

This test is the same as test #1, with
the addition of the getinfo foo-handle
in the compound to determine how Windows behaves when a request that might go async is in the middle of the compound stream.

When the server sees the compound notify request in this test it should have no pending requests to return, and so the compound notify should be forced to go async.

However, Windows 2022 returns NT_STATUS_INTERNAL_ERROR for the compound notify request.

It appears Windows 2022 might treat SMB2_OP_NOTIFY differently to other requests in a compound but I can't find this documented anywhere.

I can send test patches against Samba smbtorture to show reproduction of this locally, or can send in packet traces for any or all of these tests.

Thanks !

Jeremy.

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: t_cmd.txt
URL: <http://lists.samba.org/pipermail/cifs-protocol/attachments/20220923/2e65ac5c/t_cmd.txt>