[cifs-protocol] When will clients/applications do a smb2 session reauth
Hi, with SMB 2.1 (and higher) it's possible to do a session re-authentication without getting a STATUS_NETWORK_SESSION_EXPIRED. With SMB 2.0 STATUS_REQUEST_NOT_ACCEPTED is returned. In what situations do clients do a (pro active) reauthentication without getting STATUS_NETWORK_SESSION_EXPIRED from the server? 3.2.4.2.3.1 Application Requests Reauthenticating a User is the related section in [MS-SMB2]. What layers in the client use this feature? How can I trigger this? Is the reauthentication only used with the same user account or also to switch a session to a different user (which is possible)? BTW: is there a reason why doch...@winse.microsoft.com doesn't work anymore? metze signature.asc Description: OpenPGP digital signature ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] When will clients/applications do a smb2 session reauth
Hello Stefan, Thank you for your inquiry about file sharing protocols. One of the Open specifications team member will contact you soon. Regards, Sreekanth Nadendla Microsoft Windows Open Specifications -Original Message- From: Stefan (metze) Metzmacher [mailto:me...@samba.org] Sent: Friday, April 27, 2012 7:35 AM To: Interoperability Documentation Help Cc: cifs-protocol@cifs.org; p...@tridgell.net; Christian Ambach Subject: When will clients/applications do a smb2 session reauth Hi, with SMB 2.1 (and higher) it's possible to do a session re-authentication without getting a STATUS_NETWORK_SESSION_EXPIRED. With SMB 2.0 STATUS_REQUEST_NOT_ACCEPTED is returned. In what situations do clients do a (pro active) reauthentication without getting STATUS_NETWORK_SESSION_EXPIRED from the server? 3.2.4.2.3.1 Application Requests Reauthenticating a User is the related section in [MS-SMB2]. What layers in the client use this feature? How can I trigger this? Is the reauthentication only used with the same user account or also to switch a session to a different user (which is possible)? BTW: is there a reason why doch...@winse.microsoft.com doesn't work anymore? metze ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] [112042751520312] When will clients/applications do a smb2 session reauth
[Sreekanth and dochelp to Bcc, Casemail to Cc] [Adding Case number in subject] Hi Metz I will be assisting you with this inquiry and the case number for follow up is : 112042751520312. As stated in our specification, doch...@microsoft.com should always be used to engage our team. Any other email alias like doch...@winse.microsoft.com should not be used. We understand that some e-mail systems expand doch...@microsoft.com to a fully qualified name, such as doch...@winse.microsoft.com. However, the location of the doch...@microsoft.com mailbox may move without notice resulting in a change of the fully qualified name. We thank you for bringing this to our attention and appreciate if you can please inform other team members to send mails directly to doch...@microsoft.com Thanks Tarun Chopra. -Original Message- From: Sreekanth Nadendla Sent: Friday, April 27, 2012 7:15 AM To: Stefan (metze) Metzmacher; Interoperability Documentation Help Cc: cifs-protocol@cifs.org; p...@tridgell.net; Christian Ambach Subject: RE: When will clients/applications do a smb2 session reauth Hello Stefan, Thank you for your inquiry about file sharing protocols. One of the Open specifications team member will contact you soon. Regards, Sreekanth Nadendla Microsoft Windows Open Specifications -Original Message- From: Stefan (metze) Metzmacher [mailto:me...@samba.org] Sent: Friday, April 27, 2012 7:35 AM To: Interoperability Documentation Help Cc: cifs-protocol@cifs.org; p...@tridgell.net; Christian Ambach Subject: When will clients/applications do a smb2 session reauth Hi, with SMB 2.1 (and higher) it's possible to do a session re-authentication without getting a STATUS_NETWORK_SESSION_EXPIRED. With SMB 2.0 STATUS_REQUEST_NOT_ACCEPTED is returned. In what situations do clients do a (pro active) reauthentication without getting STATUS_NETWORK_SESSION_EXPIRED from the server? 3.2.4.2.3.1 Application Requests Reauthenticating a User is the related section in [MS-SMB2]. What layers in the client use this feature? How can I trigger this? Is the reauthentication only used with the same user account or also to switch a session to a different user (which is possible)? BTW: is there a reason why doch...@winse.microsoft.com doesn't work anymore? metze ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
[cifs-protocol] SMB1 -- proper client behavior when it does not hold an oplock
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Dochelp! I'm hoping you can help clarify some points about proper SMB1 (and maybe SMB2?) client behavior when it does not hold an oplock (at least one that allows write caching). My understanding has always been that when a client does not have an oplock that allows write caching, then it should not cache any writes - -- full stop. If an application does a write then the kernel should not return until it has been sent to the server and the reply has come back. That behavior is at least suggested in MS-CIFS, though it does not come out and state that explicitly. OTOH, Steve French suggested that that's not required by the protocol and that clients are allowed to buffer up writes briefly in order to allow the redirector to batch up small writes into a single request as long as it flushes them out in a timely fashion. That seems a little crazy to me, but I guess it's not the craziest thing in SMB1 if so... So I guess my questions are: 1) What does the protocol actually mandate? Are you allowed to briefly buffer up writes before returning to an application when the client holds no oplock? 2) What does Windows actually do in this regard? If you are not allowed to do that by the protocol, then does it follow this strictly or does it do as Steve suggests and batch up small writes until it can fill a write request? Thanks for any info you can provide! - -- Jeff Layton jlay...@samba.org -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) iQIcBAEBAgAGBQJPmuUCAAoJEAAOaEEZVoIVNAYP/AguYKBwaYTmTLMqKaMxHyEv gHiOF0dXIlvu51iHx4fvhY0cBptZwNoa2nEDWdhhEbUxnbZ8QxKw8E4BW87BbKx6 tSKAW6FD5A5m9TCA4qazYjksJYqiXtYdvtPuMSShiZErrQiir/USMD8DK5b/FYer sEU91HcOZzwaIWHb8sewxohsKvXcMaq8/Ufs7i1bmEQrx+EaA6yeF6W5aXxXtHag 0E9EcAowAd3MJZr6RglvvGJ+kgPAA7g4nhY13eA9iBSGQRPaFC/+PR1KsBwynRzV UAylnDJrbDdWsM1lpyAqRG/X7S2gYYLiOqhBYoBaaZg5yKdzcBGi829d5HBWUeQy r2CZ1IbN3rNM5UW4gW+TS1bhd+E1XiNyDDUPLad1DeIP8DhAes+aTjKHVWNev7Cw fCFt3GFl8HC/rjVQzkD4QCN/OyXyDlv745+Ud/FHgu6osJAo4F8ANU3MH+rXgbH1 mWn2N8lD/ZTJuDMlOiMmz0ABXKd2qcFn6uIE7+o8wIj59sXz+ZN23JckKk2jbNqJ puJ3mEhacQNXUs4P3jLJBqwzx1fqg9Ego+Pnh9VKm9v2lOshscwscBBroXttNE4l 4F9PZdm0KCDWa0yNJKSZxdM8WU0RBp2+9M9BVRJawnlskMh/f8cWSHDlMnx5AAon n1oPgAuAUFTCjR3tq6QO =hKCL -END PGP SIGNATURE- ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
[cifs-protocol] SMB1 -- proper client behavior when it does not hold an oplock
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sorry for the duplicate emails, but I sent this to the wrong dochelp address before. Let me try again... Hi Dochelp! I'm hoping you can help clarify some points about proper SMB1 (and maybe SMB2?) client behavior when it does not hold an oplock (at least one that allows write caching). My understanding has always been that when a client does not have an oplock that allows write caching, then it should not cache any writes - -- full stop. If an application does a write then the kernel should not return until it has been sent to the server and the reply has come back. That behavior is at least suggested in MS-CIFS, though it does not come out and state that explicitly. OTOH, Steve French suggested that that's not required by the protocol and that clients are allowed to buffer up writes briefly in order to allow the redirector to batch up small writes into a single request as long as it flushes them out in a timely fashion. That seems a little crazy to me, but I guess it's not the craziest thing in SMB1 if so... So I guess my questions are: 1) What does the protocol actually mandate? Are you allowed to briefly buffer up writes before returning to an application when the client holds no oplock? 2) What does Windows actually do in this regard? If you are not allowed to do that by the protocol, then does it follow this strictly or does it do as Steve suggests and batch up small writes until it can fill a write request? Thanks for any info you can provide! - -- Jeff Layton jlay...@samba.org -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) iQIcBAEBAgAGBQJPmuasAAoJEAAOaEEZVoIVskQP/0+D09k+8gWthZvBrpbLms1B q7ZQBcBHNCJZos7ZG+K/9ZHzGVKxtnmW2rDiQ+r5vQ/z9EK4QP3pd6V+LupoFNzI CCH3fAYgAHgl2W83I/fDNCdrtrvEK0VDYLEFZwltsk5lf5rL9PEfUoFtBq72dz0R bj6GJM8A3EaiQx431DOszuv+YG6sh50Gw+TkPOYwSpIv8fZbIydXpmlgtBT/kJCm c/M+lIYrYO5Jisv+GXoYAIOiQAIlIdD5Hw2swMSm7kEQliCxMdY9KjSR/pL6p1HY 7Pbdq1oQg/HhHQzpFmMwUMyJJqBCU5mA2Ze7Q3EUHdE1vxB9vUug0So4IQf/+lEz 1nlOYXuZrepUzjbd/zIrBXfpBuPwR0ja4+XwnaZmXgCAxUijpyomsmCNnsefLcrO 32mHheNaopDijO3S4zYrgmdk4Yrl4KxCNjMQ0q/JRlFsWAbvS98Z1vApzHXzIHND Zeh8nx698KqVh4GKpKM8KGwT9yCK5ItPqxVlhbdmhna3rjR53kzyjzza+oIOYhBv i7WMSSpRWQt1h0lVZp9oyBrq2TvNKYXbTu2me9chE44Qe7/D1c/0wpRw0Chzccdy wnuDTYM5BsBEUZHHEsr42HrdCQ0+UwJo3j8qGdF3HDvq43lx61nmDX5YO4GJVSht JSJ1jfHYiGPEWnDgUXgj =P0b9 -END PGP SIGNATURE- ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] SMB1 -- proper client behavior when it does not hold an oplock
Hello Jeff, Thank you for your inquiry about File sharing protocols. One of the Open specifications team member will contact you soon. Regards, Sreekanth Nadendla Microsoft Windows Open Specifications -Original Message- From: Jeff Layton [mailto:jlay...@poochiereds.net] On Behalf Of Jeff Layton Sent: Friday, April 27, 2012 2:34 PM To: p...@tridgell.net; cifs-proto...@samba.org; Interoperability Documentation Help Cc: smfre...@gmail.com; c...@samba.org Subject: SMB1 -- proper client behavior when it does not hold an oplock -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sorry for the duplicate emails, but I sent this to the wrong dochelp address before. Let me try again... Hi Dochelp! I'm hoping you can help clarify some points about proper SMB1 (and maybe SMB2?) client behavior when it does not hold an oplock (at least one that allows write caching). My understanding has always been that when a client does not have an oplock that allows write caching, then it should not cache any writes - -- full stop. If an application does a write then the kernel should not return until it has been sent to the server and the reply has come back. That behavior is at least suggested in MS-CIFS, though it does not come out and state that explicitly. OTOH, Steve French suggested that that's not required by the protocol and that clients are allowed to buffer up writes briefly in order to allow the redirector to batch up small writes into a single request as long as it flushes them out in a timely fashion. That seems a little crazy to me, but I guess it's not the craziest thing in SMB1 if so... So I guess my questions are: 1) What does the protocol actually mandate? Are you allowed to briefly buffer up writes before returning to an application when the client holds no oplock? 2) What does Windows actually do in this regard? If you are not allowed to do that by the protocol, then does it follow this strictly or does it do as Steve suggests and batch up small writes until it can fill a write request? Thanks for any info you can provide! - -- Jeff Layton jlay...@samba.org -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) iQIcBAEBAgAGBQJPmuasAAoJEAAOaEEZVoIVskQP/0+D09k+8gWthZvBrpbLms1B q7ZQBcBHNCJZos7ZG+K/9ZHzGVKxtnmW2rDiQ+r5vQ/z9EK4QP3pd6V+LupoFNzI CCH3fAYgAHgl2W83I/fDNCdrtrvEK0VDYLEFZwltsk5lf5rL9PEfUoFtBq72dz0R bj6GJM8A3EaiQx431DOszuv+YG6sh50Gw+TkPOYwSpIv8fZbIydXpmlgtBT/kJCm c/M+lIYrYO5Jisv+GXoYAIOiQAIlIdD5Hw2swMSm7kEQliCxMdY9KjSR/pL6p1HY 7Pbdq1oQg/HhHQzpFmMwUMyJJqBCU5mA2Ze7Q3EUHdE1vxB9vUug0So4IQf/+lEz 1nlOYXuZrepUzjbd/zIrBXfpBuPwR0ja4+XwnaZmXgCAxUijpyomsmCNnsefLcrO 32mHheNaopDijO3S4zYrgmdk4Yrl4KxCNjMQ0q/JRlFsWAbvS98Z1vApzHXzIHND Zeh8nx698KqVh4GKpKM8KGwT9yCK5ItPqxVlhbdmhna3rjR53kzyjzza+oIOYhBv i7WMSSpRWQt1h0lVZp9oyBrq2TvNKYXbTu2me9chE44Qe7/D1c/0wpRw0Chzccdy wnuDTYM5BsBEUZHHEsr42HrdCQ0+UwJo3j8qGdF3HDvq43lx61nmDX5YO4GJVSht JSJ1jfHYiGPEWnDgUXgj =P0b9 -END PGP SIGNATURE- ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
