SMB2/3 Credits (Multi-Credit) support

[Stefan (metze) Metzmacher]

Hi Jeremy,

>> while reviewing the multi-credit code that already went to master
>> a few weeks ago, I noticed some missing details in the multi-credit code.
>>
>> While debugging this I found some bugs in our credit handling code.
>>
>> I spend a lot of time testing against Windows 2012 RC.
>> I think the code in this branch, let us behave almost like a windows server.
>> https://gitweb.samba.org/?p=metze/samba/wip.git;a=shortlog;h=refs/heads/master3-credits
>>
>> The most important thing is that windows 2012 RC allows up to 8192 credits
>> (also our default), but it normally it only grants up to (8192/16) = 512
>> credits.
> 
> Interesting - do you know if this is documented anywhere in the MS docs ?
> The credit algorithm they use is not documented as far as I know.

No, not exactly, there're just the values

         default min/default max:
desktop  128/2018
server   512/8192

>> If the client uses very large credit-charge values (e.g. using all 512
>> (or 256) credits just for one request)
>> I'm able to get up to 8192 credits after a while.
>>
>> Note that it's only useful for a client to use up to 15 credits per
>> request (for 1MB reads/writes).
>>
>> With my patches we only grant up to (8192/16) = 512 credits,
>> adding more dynamic crediting between 512 and 8192 later.
> 
> That sounds reasonable.
> 
>> I'll do some more testing tomorrow, then I plan to push this to master
>> (it already passed a private autobuild once).
> 
> I noticed you removed DEFAULT_SMB2_MAX_CREDIT_BITMAP_FACTOR,
> which is fine, but I need to tell you why that was added.
> 
> What I observed back when we were advertising smaller credit
> windows was that Windows clients would request sequence numbers
> *outside* of the valid credit range.
> 
> For example, if we have a valid sequence number space of 100-200,
> then Windows clients would use requests with sequence numbers between
> 100 - 300. Note that they'd never use more than the 100 outstanding
> credits they had available, but they'd commonly miss a low
> sequence number and then use numbers above the valid range,
> finally filling in the missing low sequence number just before
> running out of credits.
> 
> So DEFAULT_SMB2_MAX_CREDIT_BITMAP_FACTOR was a heuristic added
> to allow us to cope with that. Christian worked with me on
> this and can probably also remember some details.
> 
> It sounds like you may have figured out the Windows algorithm,
> and by restricting to 16th you may not hit the problem
> DEFAULT_SMB2_MAX_CREDIT_BITMAP_FACTOR was added to solve.
> 
> I'd keep a close eye on this however, as normal testing
> didn't reveal the seuqnce number problem, it took released
> code in the wilds of IBM internal to have the problem be
> seen.

DEFAULT_SMB2_MAX_CREDIT_BITMAP_FACTOR was just there to hide real bugs.

1. If the client starts with a SMB1 negprot, we never removed seqnum 0.

2. when moving the seqnum_low, we didn't calculate the bitmap_offset
correct.

3. we moved seqnum_low + 1 (as lowest value) instead of id == seqnum_low.

4. we didn't stop granting credits if the client didn't use seqnum_low.

I've tested my patches a lot, using a modified smbtorture
to check how windows behaves and in what situation it stops granting credits
and disconnect the connection if a use an invalid seqnum.

metze

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20120628/c6bfa197/attachment.pgp>