readx and CAP_LARGE_READX

[George Colley]

Sorry for being late to this conversation. Thursby code and the next  
release of smbfs from Apple will support very large reads and writes  
to servers that support this option. There are several problems with  
using anything bigger that 63K.

First you can write 128K to Windows XP/2000/2003 servers, but you  
can't read more than 63K. I believe this is just a bug in Windows.  
Second you cannot use the large write to windows systems if smb  
signing is turn on. You can use large reads, go figure. This has been  
a known issue since NT4, you would think they have it fixed by now.

So I have large reads and writes working with Samba 3.0.23, but I am  
not sure how to tell the difference between 3.0.23 and 3.0.10. Tried  
several work around but known work. Still working on this issue.


On Dec 7, 2006, at 4:26 PM, James Peach wrote:

> On Dec 7, 2006, at 4:08 PM, tridge at samba.org wrote:
>
>> James,
>>
>>> cifsdd is stupid by design. I wrote is because I wanted a tool to  
>>> give
>>> me precise control over how I/O is done on the wire. If windows
>>> doesn't implement the SNIA readX behaviour, then I am perfectly  
>>> happy
>>> for cifsdd to not work.
>>
>> ahh, ok, I had misunderstood the purpose of the tool then. What  
>> you've
>> really done is written a command line interface to the libcli/raw
>> library (I designed the raw library with the same philosophy as you
>> had for cifsdd - that it would do exactly whats asked of it, even if
>> the server can't handle it).
>>
>>> However, Samba3 does implement the SNIA readX behaviour (and there  
>>> are
>>> non-Windows clients in the wild that take advantage of this).
>>
>> which clients take advantage of this, apart from cifsdd?
>
> OSX can (or will). I believe the Thursby client does too.
>
>>> I'm arguing that the Samba4 libcli should let me take advantage of
>>> the Samba3 implementation if it is there.
>>
>> ok - I agree now that I understand the purpose :-)
>>
>> I'll look at changing libcli to make this work.
>
> Thanks. The patch I posted earlier did this, but not very nicely.
>
>>> For cifsdd I try to ask libcli to negotiate a buffer size large  
>>> enough
>>> for the size of the I/Os I want to do. IIRC I proceed to ignore the
>>> buffer size that was actually negotiated, so it sounds like this
>>> "behaviour" could bite me.
>>
>> yes, it probably will.
>>
>> btw, if you want to investigate this behaviour, this is what I did to
>> discover why w2k3 is behaving as it is. I setup a SMBwriteX with a  
>> bit
>> larger write than the negotiated buffer size, connected to a w2k3 DC,
>> with signing enabled. Then I sent the writex, but didn't send all the
>> bytes of the request. I sent just the header and the first part of  
>> the
>> data, then sent the rest of the data 1 byte at a time, with a small
>> delay (a fraction of a second) between the bytes. I watched with a
>> sniffer.
>
> Are you sure that this test is not triggering a DoS detection  
> mechanism? In a former life I was involved in some work on the  
> sunrpc libraries that rejected activities like that on that basis  
> that it was almost certainly a malicious client.
>
>> What you see is that the NT_STATUS_ACCESS_DENIED (the normal signing
>> error) comes back as soon as you have sent more bytes than the
>> negotiated buffer size. It comes back _before_ you have sent the full
>> request. This means that the signing must be being done on only the
>> partial request, which means it's a bug in how much data they pass to
>> the signing function, rather than a bug in the signing code itself.
>
> Does it still give NT_STATUS_ACCESS_DENIED independently of whether  
> you are drip-feeding the data?
>
>>> Maybe I should to add an argument to cifsdd to relax it's I/O
>>> behaviour. Something that means "try to do what I told you, but play
>>> it safe so things will actually work".
>>
>> I think that should probably be the default actually, and have an
>> option to force it to try operations that will fail with windows
>> servers if the user wants them. Or have an environment variable to
>> enable that behaviour.
>
> OK, that sounds sane.
>
> --
> James Peach | jpeach at samba.org
>