Hi Matthieu: Is the dump for just the stage header or the whole PDU ( starting from COMM_BOP). The beginning 00 00 00 00 08 00 00 00 does not match any.
Regards, Obaid Farooqi Escalation Engineer | Microsoft Exceeding your expectations is my highest priority. If you would like to provide feedback on your case you may contact my manager at allis...@microsoft.com -----Original Message----- From: Matthieu Patou [mailto:m...@samba.org] Sent: Tuesday, October 18, 2011 4:50 PM To: Obaid Farooqi Cc: MSSolve Case Email; p...@tridgell.net; cifs-proto...@samba.org Subject: Re: [REG:111091961780016] Re: - About stage_header data On 18/10/2011 01:29, Obaid Farooqi wrote: > Hi Mathieu: > We have finished our investigation on your questions regarding MS-FRS1. I am > providing answers to your questions in a Q&A format for clarity. > > Q. In particular, paragraph 2.2.3.2 CHANGE_ORDER_COMMAND define a > status attribute but in 3.3.4.4.7 we are told about a "state" attribute: > > A. Your observation is correct that “state” and “status” are the same. In a > future release of MS-FRS1, “ULONG Status;” will be replaced by “ULONG State;” > in section “2.2.3.2 CHANGE_ORDER_COMMAND”. > > Q. … in the dump (from a windows > server) the status filed had the value > FRSRPC_CO_STATUS_REMOTE_CO_STAGING_STARTED (0x6) not 1 not 5. > > It's stated that "PartnerAckSeqNumber MUST be set to 0." in the dump > partern_ack_sequence_number is set to 418. > It's stated that "AckVersion MUST be set to 0." in the dump ackVersion is set > to 129598581805743814. > > A. My code browsing as well as my debugging confirms that the values > documented are correct. I have requested a binary dump of the message from > you couple times but have not received anything from you yet. I assume, as I > mentioned before, there is a problem with NDR dump that you used. If you > believe your dump is correct please send me the binary dump of the whole PDU > and I’ll be happy to hand-parse it and go from there. See the attached binary dump. It's not the exact dump that I parsed with ndrdump in my first email but it's similar > > Q. Can you tell me what is the use of the command's flag for the upstream > partner (the receiver of the file). > > A. FRS1 code is deprecated and is very old. It does not follow lot of coding > best practices that are considered normal and routine nowadays. My code > browsing shows that there is no error checking performed on the flags in > change order by the receiver. The use of MUST for setting these flags in the > document is an indication that if these flags are not set correctly then > errors will happen on the receiver. Flags in change orders are used to > process the change order correctly and without them replication would not > function correctly. Receiver assumes the flags as sent by the upstream > partner are correct and processing decisions are made based on that. The > function of each flag and the values that need to be set is documented in > MS-FRS1. If you have a specific question about a flag or flags, please feel > free to contact us. Ok but there is two ways for the downstream partner to indicate a problem to the upstream: reply to the DCE / RPC request with a rpc status not OK or send a request with command REMOTE_CO_DONE but with a status not ok (in the REMOTE_CO chunk). > I noticed that your terminology does not agree with MS-FRS1 in terms of > upstream and downstream partner. As per section “1.1 Glossary” of MS-FRS1: > > Downstream Partner: The partner that receives change orders, files, and > folders. > Upstream Partner: The partner that sends out change orders, files, and > folders. Oh thanks I tend to mix them .... > Please let me know if it answers your question. > > Regards, > Obaid Farooqi > Escalation Engineer | Microsoft > > Exceeding your expectations is my highest priority. If you would like > to provide feedback on your case you may contact my manager at > allis...@microsoft.com > > > -----Original Message----- > From: Obaid Farooqi > Sent: Thursday, October 13, 2011 3:29 PM > To: 'Matthieu Patou' > Cc: MSSolve Case Email; 'p...@tridgell.net'; 'cifs-proto...@samba.org' > Subject: RE:[REG:111091961780016] Re: - About stage_header data > > Hi Matthieu: > Can you please provide information requested in the my previous email? > > Regards, > Obaid Farooqi > Escalation Engineer | Microsoft > > Exceeding your expectations is my highest priority. If you would like > to provide feedback on your case you may contact my manager at > allis...@microsoft.com > > > -----Original Message----- > From: Obaid Farooqi > Sent: Monday, October 10, 2011 12:44 PM > To: 'Matthieu Patou' > Cc: MSSolve Case Email; 'p...@tridgell.net'; 'cifs-proto...@samba.org' > Subject: RE:[REG:111091961780016] Re: - About stage_header data > > Hi Matthieu: > I looked in code as well as debugged it and it is not obvious why the state > be set to 6. Is it possible that the parser is not parsing the data correctly? > You can send me the whole packet that is sent by the Windows server and I'll > hand parse it to see if that is the case or if you prefer, you can hand parse > it yourself and let me know. > If it is possible for you to get a time travel trace of ntfrs.exe on the > Windows Server that sent CMD_RECEIVING_STAGE, that would be great. > The file transfer space is ephemeral so please let me know when you can send > the traces and I'll set up a file transfer space for this and will send you > the latest version of the Time travel trace installation binary. > > Regards, > Obaid Farooqi > Escalation Engineer | Microsoft > > Exceeding your expectations is my highest priority. If you would like > to provide feedback on your case you may contact my manager at > allis...@microsoft.com > > > -----Original Message----- > From: Obaid Farooqi > Sent: Monday, October 10, 2011 12:34 PM > To: "Obaid Farooqi"<oba...@microsoft.com> > Cc: "MSSolve Case Email"<casem...@microsoft.com>; > "p...@tridgell.net"<p...@tridgell.net>; > "cifs-proto...@samba.org"<cifs-proto...@samba.org> > Subject: [REG:111091961780016] Re: - About stage_header data > > Hello Obaid, > >> Hi Matthieu: >> Can you please elaborate more on the following question? >> "Can you tell me what is the use of the command's flag for the > upstream partner (the receiver of the file)." >> The flags for CHANGE_ORDER_COMMAND are documented in section 2.2.3.2. > Can you please be more specific? > My question is this status information just informative, or should the > upstream partner do some checks on it, and what about for the downstream > partner. > > The fact it's stated that the downstream partner MUST set a particular value > seems to indicate that checks are made on this attribute. > > Matthieu. > > -- > Matthieu Patou > Samba Team > http://samba.org > > > > Microsoft is committed to protecting your privacy. Please read the Microsoft > Privacy Statement for more information.The above is an email for a support > case from Microsoft Corp.REPLY ALL TO THIS MESSAGE or INCLUDE > casem...@microsoft.com IN YOUR REPLY if you want your response added to the > case automatically. For technical assistance, please include the Support > Engineer on the TO: line. Thank you. -- Matthieu Patou Samba Team http://samba.org _______________________________________________ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
