[PATCH] Fix for bug #9706 - Parameter is incorrect on Android

[Stefan (metze) Metzmacher]

Hi Jeremy,

>> If nobody complains till tomorrow I will review again and push it. Time to 
>> knock off now ;)
> 
> So hang fire on pushing this please (Michael and Metze also :-),
> as I decided I needed to do one more test before I know *exactly*
> how things should behave here (and I'm home now so this will have to
> wait until I get back into work tomorrow and back to my W2K12
> VM box :-).
> 
> What does Windows return for a readX call of length: 0x22000001 ?
> This is way beyond any NetBIOS possible length even if using the
> unix extensions trick of using 24 bit lengths.
> 
> There are 3 options.
> 
> 1). Return invalid parameter (this is what we currently do).
> 2). Return a read of length 1 (this means they mask with 0x1FFFF
> and truncate above length 0x10000).
> 3). Return a read of length 0x10000 (this means they just treat
> all reads > 0x10000 as requests of length 0x10000).
> 
> And of course I want to test with the client sending CAP_LARGE_READX
> and not sending CAP_LARGE_READX.

Thanks! These are exactly my questions.

I think testing 0xFFFE0001 would also be good, as well as 0x00020001.

It would be also good to test against port 139 and 445 to see if there's
a difference.

Currently I think we need the following:

If we haven't advertised CAP_LARGE_READX in our negprot response (I
don't know if this can be configured)
we ignore set upper_size = 0.

If upper_size is 0xFFFF we set it to 0.

If we have advertised CAP_UNIX and CIFS_UNIX_LARGE_READ_CAP we set
max_pdu_len = 0xFFFFFF, otherwise
to 0x1FFFF.

Maybe alter max_pdu_len depending on signing, encryption and chaining.

Set max_read_len = max_pdu_len - header, depending on the pending tests
to a lower level is we haven't advertised CAP_UNIX and/or
CIFS_UNIX_LARGE_READ_CAP.

Depending on an old broken samba client (get_remote_arch() == RA_SAMBA)
we need
to adjust the max_pdu_len/max_read_len values.

Pending on the tests we return an error if the requested size is higher than
max_read_len or we truncate the value.

Can you generate a capture against w2k8r2 and w2012, so that we'll
always have a
good reference if this pops up again in future...

> So I'm going to do those tests before deciding if this patchset
> is the correct one or might need further changes in the patch
> that modifies the server read response (I'm pretty happy with
> the client-side changes in the patchset, but we might was well
> keep it all in one changeset).

I think we should keep it all in one changeset.
Currently I think the client changes (execpt the tcp_len patch)
are just for testing.

metze


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