Large RPC bug found, I think
jra at dp.samba.org
jra at dp.samba.org
Wed Mar 26 02:13:57 GMT 2003
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.
More information about the samba-technical
mailing list