On 2015-10-05 at 14:50 -0500, Steve French wrote: > On Mon, Oct 5, 2015 at 9:44 AM, Tom Talpey <ttalpey@xxxxxxxxxxxxx> wrote: > >> -----Original Message----- > >> From: linux-cifs-owner@xxxxxxxxxxxxxxx [mailto:linux-cifs- > >> owner@xxxxxxxxxxxxxxx] On Behalf Of Steve French > >> Sent: Saturday, October 3, 2015 10:03 PM > >> ... > >> I don't know if channel sequence number in the SMB3 request would also > >> need to be incremented on disconnect though (the documentation is > >> confusing on that in MS-SMB2) in the case where we only have one > >> channel. > > > > There's nothing special about replay on one channel, after any disconnect you should increment the channel sequence so the server's replay detection can work properly. > > > > Can you point me to the MS-SMB2 text that you find confusing? We can address it. > > > (the doc text in 3.2.4.1 and 3.2.7.1 of MS-SMB2 seems to > conflict) > > On disconnect "If Connection.Dialect belongs to the SMB 3.x dialect > family, and if the Session has more than one channel in > Session.ChannelList, the client MUST perform the following actions: > > "Session.ChannelSequence MUST be incremented by 1." > > but 3.2.4.1 indicates that it is not just for multichannel but also > for PersistentHandle that it must be incremented (see below) > > "If Connection.Dialect belongs to the SMB 3.x dialect family and if > Connection.SupportsMultiChannel or > Connection.SupportsPersistentHandles is TRUE, the > client MUST set ChannelSequence in the SMB2 header to Session.ChannelSequence." I don't see a contradiction / conflict here: - 3.2.7.1 tells when to bump the seqnum. - 3.2.4.1 tells when to send it to the server (this makes no statement about the value) So the document seems to indicate this: Bumping the channel sequence number is only done by the Windows client upon connection loss on a multi-channel session (i.e. a real one, with more than one channel) and not for a single channel session (also not on a formerly multi-channel session, when the last channel goes down). A new smbtorture test case that I am currently reviewing indicates that the windows server is OK with this client behaviour (i.e. not bumping when the last channel of a session goes down). Cheers - Michael
Attachment:
signature.asc
Description: PGP signature
