[cifs-protocol] [REG:111091961780016] Re: - About stage_header data

Matthieu Patou mat at samba.org
Tue Oct 18 15:50:26 MDT 2011


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 allisong at microsoft.com
>
>
> -----Original Message-----
> From: Obaid Farooqi
> Sent: Thursday, October 13, 2011 3:29 PM
> To: 'Matthieu Patou'
> Cc: MSSolve Case Email; 'pfif at tridgell.net'; 'cifs-protocol at 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 allisong at microsoft.com
>
>
> -----Original Message-----
> From: Obaid Farooqi
> Sent: Monday, October 10, 2011 12:44 PM
> To: 'Matthieu Patou'
> Cc: MSSolve Case Email; 'pfif at tridgell.net'; 'cifs-protocol at 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 allisong at microsoft.com
>
>
> -----Original Message-----
> From: Obaid Farooqi
> Sent: Monday, October 10, 2011 12:34 PM
> To: "Obaid Farooqi"<obaidf at microsoft.com>
> Cc: "MSSolve Case Email"<casemail at microsoft.com>; "pfif at tridgell.net"<pfif at tridgell.net>; "cifs-protocol at samba.org"<cifs-protocol at 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 casemail at 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: command_receiving_state
Type: application/octet-stream
Size: 1924 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/cifs-protocol/attachments/20111018/02b48ca5/attachment.obj>


More information about the cifs-protocol mailing list