[cifs-protocol] 112080853508014 SMB3 channel sequence

[Sreekanth Nadendla]

Dochelp moved to BCC.
Casemail added to CC.

Hello Stefan,
                       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 ?


Regards,
Sreekanth Nadendla
Microsoft Windows Open Specifications

-----Original Message-----
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

Hi DocHelp,

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.

metze