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

[Jeremy Allison]

On Wed, Mar 13, 2013 at 01:00:30PM +1100, Andrew Bartlett wrote:
> On Tue, 2013-03-12 at 09:43 -0700, Jeremy Allison wrote:
> > On Tue, Mar 12, 2013 at 09:24:40AM -0700, Jeremy Allison wrote:
> > > What shall we test here ? We need to verify we act
> > > the same as Windows, so we'll need to find a way
> > > to remove the sending "Samba" string in the client
> > > libraries (or to explicitly ignore it in the server)
> > > so we don't always fall into the "it's a Samba client,
> > > look at the top bits' case.
> > 
> > Aha ! Looks like I can do this by restricting the
> > protocol types request in smbXcli_negprot_send()
> > to use max and min protocols of PROTOCOL_NT1.
> > 
> > Shouldn't be too hard to add these then.
> > 
> > Updated patch including tests to follow. On
> > another note, I'm starting to think we shouldn't
> > look at lp_unix_extensions() in this code path
> > at all, as it really makes no difference in
> > how we should respond to a large read request.
> > 
> > The only things we should look at are the
> > 0xFFFF value, the RA_SAMBA arch, and the
> > CAP_LARGE_READX negotiate.
> 
> Why do we need to look for RA_SAMBA, if a client has sent
> CAP_LARGE_READX?

Because due to changes in our client library,
currently the 4.0.x client code doesn't send CAP_LARGE_READX
or CAP_LARGE_WRITEX to the server in the sessionsetupX
capabilities field. The 3.6.x client code (and also
the MacOXC client) do, and I think we should too
(even though a Windows server ignores it).

Jeremy.