[cifs-protocol] [REG: 112080853508014] SMB3 channel sequence questions. When is Open.OutstandingPreRequestCount supposed to be decremented or reset
edgaro at microsoft.com
Wed Aug 8 14:27:25 MDT 2012
I am taking care of this question (case 112080853508014).
After reviewing the source code, I will be opening a document bug.
I will update you as soon as I have news.
From: Sreekanth Nadendla
Sent: Wednesday, August 08, 2012 10:38 AM
To: Stefan (metze) Metzmacher
Cc: pfif at tridgell.net; cifs-protocol at cifs.org; MSSolve Case Email
Subject: 112080853508014 SMB3 channel sequence
Dochelp moved to BCC.
Casemail added to CC.
Thank you for your inquiry about channel sequence verification in SMB3 file sharing protocol. We have created three separate incidents to track the investigation of these specific issues mentioned in your e-mail. You will be contacted by Open specifications team members shortly.
112080853508014 SMB3 channel sequence questions. When is Open.OutstandingPreRequestCount supposed to be decremented or reset
112080854980596 SMB3 channel sequence questions. What happens when 16-bit channel sequence number wraps
112080855623402 SMB3 channel sequence questions. Channel sequence get out of sync ? if overflow results during idle file handle, can server detect ?
Microsoft Windows Open Specifications
From: Stefan (metze) Metzmacher [mailto:metze at samba.org]
Sent: Tuesday, August 07, 2012 10:21 PM
To: Interoperability Documentation Help
Cc: pfif at tridgell.net; cifs-protocol at cifs.org
Subject: SMB3 channel sequence
I have some questions regarding the channel sequence verification of SMB 3.00.
- When is Open.OutstandingPreRequestCount supposed to be decremented or reset?
- What happens on an 16-bit overflow?
From the documentation it looks like, the server would
always reject write/ioctl/setinfo with STATUS_FILE_NOT_AVAILABLE
once the channel sequence wrapped.
- As the client maintains the channel sequence on the session,
while the server maintains it on the open, it seems not to be
unlikely that the values get out of sync.
(Assuming there's a way to handle the general 16-bit overflow)
It could happen that the client opened a file and doesn't
use the handle for a long time (while the 16-bit value got an overflow
on the client). This would mean that the server can know if
a channel sequence is older or newer than the last one.
More information about the cifs-protocol