> -----Original Message----- > From: Michael Adam [mailto:obnox@xxxxxxxxx] > Sent: Thursday, October 15, 2015 7:15 AM > To: Steve French <smfrench@xxxxxxxxx> > Cc: Tom Talpey <ttalpey@xxxxxxxxxxxxx>; linux-cifs <linux- > cifs@xxxxxxxxxxxxxxx>; samba-technical <samba-technical@xxxxxxxxxxxxxxx> > Subject: Re: Channel Sequence handling - was RE: [PATCH] [SMB3] Send > durable handle v2 contexts when use of persistent handles required > > 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) Correct. These are two distinct requirements. > 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). The document indicates this, but the text is incomplete. Channel sequence management is not limited to this case. We're looking into this (section 3.2.7.1) and I hope to clarify it soon. There are some improvements in flight. > > 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). Not sure what you mean by "server is OK with this". The server uses the channel sequence number to detect whether the client experienced a disconnect. Remember, the connection can break on one side before the other. If the sequence doesn't change, there is no end-to-end detection, so it becomes a probabilistic issue whether the orphaned operations replay properly. With proper channel sequence management, this behavior is guaranteed. Bottom line, bump the channel sequence on any disconnect when the server indicated it inspects the field, i.e. has set SMB2_GLOBAL_CAP_MULTI_CHANNEL and/or SMB2_GLOBAL_CAP_PERSISTENT_HANDLES at negotiate time. Tom. -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
