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.