Re: Channel Sequence handling - was RE: [PATCH] [SMB3] Send durable handle v2 contexts when use of persistent handles required

[Michael Adam <obnox-eUNUBHrolfbYtjvyW6yDsg@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 2382 bytes --]

On 2015-10-05 at 14:50 -0500, Steve French wrote:
> On Mon, Oct 5, 2015 at 9:44 AM, Tom Talpey <ttalpey-0li6OtcxBFHby3iVrkZq2A@public.gmane.org> wrote:
> >> -----Original Message-----
> >> From: linux-cifs-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org [mailto:linux-cifs-
> >> owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org] 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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]