Large RPC bug found, I think

Ronan Waide waider at waider.ie
Wed Mar 26 01:58:49 GMT 2003


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.

Cheers,
Waider.
-- 
waider at waider.ie / Yes, it /is/ very personal of me.

"For those that dont remember, PI is the big number that begins with three."
   - http://www.facade.com/legacy/amiinpi/


More information about the samba-technical mailing list