Re: Large RPC bug found, I think
On March 26, [EMAIL PROTECTED] said: 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 ? The bug I'm seeing is that Samba isn't getting a response to the WriteAndX request it's sending and times out. Also, I'd feel happier if you tested and compared with Win2000/WinXP rather than WinNT as NT is rather old these days Yup, but I'm working with what I've got. I'll see if I can run a chack against a Win2K box, but solving this problem for NT4 gets an immediate problem off my list. Jeremy. Cheers, Waider. -- [EMAIL PROTECTED] / Yes, it /is/ very personal of me. It's too bad that most people don't get the fact that an object-oriented programming style has exactly nothing to do with the programming language you use. - Jamie Zawinski
Large RPC bug found, I think
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. -- [EMAIL PROTECTED] / 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/
Re: Large RPC bug found, I think
On Wed, Mar 26, 2003 at 01:58:49AM +, 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.
