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

Jeremy Allison jra at samba.org
Fri Mar 15 12:40:21 MDT 2013


On Fri, Mar 15, 2013 at 07:24:05AM +0100, Stefan (metze) Metzmacher wrote:
> 
> 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...

Ok, I've done the tests. Looks like the correct response
is to return shorter reads than what the client asks if
the reads are out of range. The only case where we should
still fail is when the read request out of range and is
done in an andX chain, so I've left that code check in
place.

I have a modified server patch that does this. It'll make
Andrew happy as we no longer need to look at RA_SAMBA, as
we just cope in the same way as Windows does with whatever
the client asks for. All we do is modify max_pdu to cope
with what the client told us it can cope with. Client tests
also expanded to cope with signed+sealed requests as well
as the new read values.

I'll post on the bug and a new patchset here shortly.

As this is a new way of handling reads I think we shouldn't
add this to 3.6.x, as the code there already copes with
all clients we currently know about (MacOSX, Samba, CIFSFS,
Android, jCIFS etc.).

Cheers,

	Jeremy.


More information about the samba-technical mailing list