Large RPC bug found, I think

[jra at dp.samba.org]

On Wed, Mar 26, 2003 at 01:58:49AM +0000, Ronan Waide wrote:
> Ok, I think I've figured this out, but since I'm relatively new to
> Samba internals I'm not entirely clear on how to fix it, or what I
> might break with my "fix".
> 
> In a large RPC call, such as an EnumPrinters 2 call with a big buffer,
> the DCE/RPC stuff gets split into several SMB messages and tossed into
> a WriteAndX loop. Running a comparison between Samba/NT4 and NT4/NT4,
> I noticed the following:
> 
> * For all RPC traffic, if the RPC is unfragmented Samba sets both
>   RPC_HDR_FIRST and RPC_HDR_LAST flags. NT4 sets neither if there's
>   only as single RPC block. This is in rpc_api_pipe_req (possibly
>   elsewhere). It's easily fixed, but I don't know if setting both
>   flags is required behaviour for some other Windows version.
> 
> * The RPC bind I'm seeing has a max tx/rx buffer size of 5680
>   bytes. This is independant of whether I use Samba or NT4 as the
>   client.
> 
> * NT4 sends RPCs via WriteAndX in chunks of 4292 bytes and 1392 bytes
>   (to make 5680 bytes per pair of WriteAndX requests) using the Raw
>   Pipe Write, so two bytes represent the length of the data and the
>   payload is 4290 bytes. As a side note, this length field throws
>   ethereal off being able to decode these packets, as best I can
>   tell.
> 
> * Samba sends RPCs chunked as 4096 bytes and 1584 bytes. It's not
>   using the Raw Pipe Write.
> 
> And now, what I think are bugs as opposed to implementation details:
> * NT4 only sets PIPE_START_MESSAGE on the very first packet; Samba
>   sets this flag on all packets.
> 
> * NT4 sets the WriteAndX "remaining" field to 5680 (max tx size) for
>   the first packet and 1390 (max tx less size of first packet) for the
>   second packet. Samba sets the "remaining" field to the packet size
>   if PIPE_START_MESSAGE is set, and to zero
>   otherwise. (code in cli_issue_write)
> 
> * Lastly, from the packet traces it appears as if Samba issues each
>   pair of writes before waiting for a response, while NT only issues a
>   new write once it's got the previous response.
> 
> I've got as far as getting the PIPE_START_MESSAGE flag working
> correctly. PIPE_RAW_MODE doesn't appear to be implemented in the
> low-level SMB write stuff. I'm not clear on a clean way of fixing the
> "remaining" field, though. Perhaps someone with a bit more
> understanding of this code could use the above to determine if I have,
> in fact, found a bug that needs fixing.

What is the bug you're trying to fix ? ie. What is the behaviour
that Windows shows that is not correct with the Samba code ?

Also, I'd feel happier if you tested and compared with Win2000/WinXP
rather than WinNT as NT is rather old these days....

Jeremy.