[cifs-protocol] [REG:111111804605994] RE: data checksum value in FRS
hongweis at microsoft.com
Tue Nov 29 15:19:33 MST 2011
While sending the CMD_REMOTE_CO command, the upstream should always include the MD5 hash which would allow the downstream to determine if it has already got this change order, maybe from some other partner. From the examples you provided, it appears that it is related to the behavior of CS_SEND_STAGE command. This command is sent by the downstream. For this command, the MD5 hash is included only if the downstream has an existing file of the name included in the change order sent from the upstream. It obviously cannot compute a MD5 hash if it has no such file and therefore sets it to NULL. This is the reason why you saw this behavior.
Please let me know if you have more questions.
From: cifs-protocol-bounces at cifs.org [mailto:cifs-protocol-bounces at cifs.org] On Behalf Of Matthieu Patou
Sent: Thursday, November 17, 2011 3:48 PM
To: cifs-protocol at samba.org; pfif at tridgell.net; Interoperability Documentation Help
Subject: [cifs-protocol] data checksum value in FRS
Paragraph 126.96.36.199DATA_EXTENSION_CHECKSUM of MS-FRS1 indiciate about the data checksum:
Data: MUST be a 128-bit MD5 digest of staging file and attributes, as specified in [RFC1321].
See section 188.8.131.52 for how the MD5 digest is constructed on a staging file and attributes.
Section 184.108.40.206 didn't bring much more information, but it seems while looking at a replication (initial + regular) between 2 DCs that the checksum attribute is sometime omitted (it's 16 null bytes).
Like in packet 3286 in the attached trace.
At the opposite in packet 5300 we have a non null checksum, can you explain in which case the checksum can or must be null ?
The trace is attached to this email.
More information about the cifs-protocol