Edgar, I will work with Bryan today to see if I can successfully decrypt an exported key. My attempts so far have failed. I am trying a new toolkit to see if I get different results. I could not find a way to get OpenSSL to decrypt the file without requiring a VI.
Chris -)----- On Tue, Jun 21, 2011 at 03:49:51PM +0000, Edgar Olougouna wrote: > Chris, > > Please let me know whether this helps. > > QUESTION 1: From what input is the Initialization Vector (IV) derived? > Is it constant, derived from the initial passphrase, or derived > from the SHA256 of the passphrase? > > QUESTION 2: What algorithm is used to derive the IV or, if the IV is > constant, what values are used? > > No initialization vector is used during the encryption. > > QUESTION 3: Is the passphrase handled as Unicode or ASCII? > I'm Assuming Unicode. > > That???s correct, the passphrase is handled as a Unicode string. > > QUESTION 4: Is the AES mode used AES-CBC? AES-ECB? Other? > > The chaining mode is cipher block chaining (CBC). > > QUESTION 5: There isn't any salt used, is there? > > No, there isn???t any salt. > > QUESTION 6: You did write "prepended", so if the file I exported is 80 > bytes long, it should be: > [32-bytes SHA256(X)] + [48-bytes X] > ...where X is the server secret. > > The plaintext buffer is ( [32-bytes SHA256(X)] + X). However, because the > encryption adds some overhead, the encrypted file may be slightly longer than > the plaintext buffer. Therefore, the secret in this scenario is not > necessarily 48 bytes in length. > > Regards, > Edgar > > -----Original Message----- > From: Edgar Olougouna > Sent: Monday, June 20, 2011 11:32 AM > To: 'Christopher R. Hertel' > Cc: [email protected] > Subject: RE: [cifs-protocol] [REG:111061756137964] Encryption of the key for > "netsh branchcache??? importkey and exportkey. > > Chris, > > I will follow-up as soon as I have the answers. > > Thanks, > Edgar > > -----Original Message----- > From: Christopher R. Hertel [mailto:[email protected]] > Sent: Saturday, June 18, 2011 10:53 PM > To: Edgar Olougouna > Cc: [email protected] > Subject: Re: [cifs-protocol] [REG:111061756137964] Encryption of the key for > "netsh branchcache??? importkey and exportkey. > > Okay, I'm wrong. The IV does make a difference. > > So... My questions again: > > QUESTION: From what input is the Initialization Vector (IV) derived? > Is it constant, derived from the initial passphrase, or derived > from the SHA256 of the passphrase? > > QUESTION: What algorithm is used to derive the IV or, if the IV is > constant, what values are used? > > QUESTION: Is the passphrase handled as Unicode or ASCII? > I'm Assuming Unicode. > > QUESTION: Is the AES mode used AES-CBC? AES-ECB? Other? > > Two More > > QUESTION: There isn't any salt used, is there? > > QUESTION: You did write "prepended", so if the file I exported is 80 > bytes long, it should be: > [32-bytes SHA256(X)] + [48-bytes X] > ...where X is the server secret. > > I just can't seem to get this to decipher, and it's probably just something > basic that I'm missing... like the IV. > > Chris -)----- > > Christopher R. Hertel wrote: > > Okay, never mind the IV part. I don't think that the IV actually > > makes a difference when decrypting. > > > > ...but I could be wrong. > > > > Christopher R. Hertel wrote: > >> Edgar, > >> > >> There is a little more information that I will need in order to make > >> this work. In particular, the AES encryption algorithm makes use of > >> an Initialization Vector which is typically derived from the > >> passphrase, as is the key. > >> > >> Your description tells me how the key is derived, but not how the IV is > >> derived. > >> > >> QUESTION: Is the IV derived from the initial passphrase or from the > >> SHA256 of the passphrase? ...or is it a constant? > >> > >> QUESTION: What algorithm is used to derive the IV or, if the IV is > >> constant (including NULL), what values are used? > >> > >> QUESTION: Is the passphrase handled as Unicode or ASCII? > >> I'm Assuming Unicode. > >> > >> QUESTION: Is the AES mode used AES-CBC? AES-ECB? Other? > >> > >> Thanks. > >> > >> Chris -)----- > >> > >> Edgar Olougouna wrote: > >>> Chris, > >>> > >>> The algorithm is as follows. > >>> > >>> Let???s assume, Bs is the server configured binary string (or whatever is > >>> generated if none was configured) for the secret. > >>> Let???s assume, Ks is the server secret, by definition Ks is SHA-256 hash > >>> of Bs. > >>> > >>> When you run "netsh branchcache exportkey???, the key file is encrypted > >>> as follows: > >>> ??? A buffer is generated, consisting of Bs prepended with Ks. > >>> ??? The buffer is encrypted using the AES-256 algorithm. The > >>> SHA-256 hash of the passphrase string, excluding the string???s NULL > >>> terminator, is used as the encryption key. > >>> ??? The resulting encrypted buffer is written to the output file. > >>> > >>> During import (netsh branchcache importkey), the input file (which was > >>> the output file in the export) is decrypted using the SHA-256 hash of the > >>> passphrase as key. The value of Bs is validated against Ks, which is the > >>> SHA-256 hash of Bs. > >>> > >>> NOTE: > >>> I am pretty sure you have seen this is the document, but for a refresher > >>> for a larger audience, the server secret key is defined in MS-PCCRC, as a > >>> SHA-256 hash of an arbitrary length binary string (see excerpts below). > >>> > >>> MS-PCCRC > >>> > >>> > >>> 1.1 Glossary > >>> server secret: A SHA-256 hash of an arbitrary length binary string stored > >>> on the server. > >>> 1.3 Overview > >>> In order to ensure that cache content retrieval communications are at > >>> least as secure as a normal client's communications with a content > >>> server, all content servers must be configured with a binary secret value > >>> of arbitrary length. This secret is used as a key to derive secret keys > >>> to be used to secure communications between the peers or between peers > >>> and a Hosted Cache. If the secret value is not configured, it is > >>> automatically generated. > >>> > >>> Best regards, > >>> Edgar > >>> > >>> -----Original Message----- > >>> From: Edgar Olougouna > >>> Sent: Friday, June 17, 2011 10:49 AM > >>> To: 'Christopher R. Hertel' > >>> Cc: [email protected] > >>> Subject: RE: [cifs-protocol] [REG:111061069959469] BranchCache and SMB2: > >>> Questions specific to BranchCache. > >>> > >>> Chris, > >>> > >>> Regarding the question on the server secret, I will be replying shortly > >>> and describe the algorithm in a new thread [REG:111061756137964] > >>> Encryption of the key for "netsh branchcache??? importkey and exportkey. > >>> That way you can achieve the decryption of the exported server secret and > >>> verify your implementation. > >>> > >>> Regarding your feedback on the glossary definition of "segment secret" in > >>> [MS-PCCRC]... I have passed on your observations to the product team. > >>> > >>> Thanks, > >>> Edgar > >>> > >>> -----Original Message----- > >>> From: Christopher R. Hertel [mailto:[email protected]] > >>> Sent: Friday, June 17, 2011 12:11 AM > >>> To: Edgar Olougouna > >>> Cc: [email protected] > >>> Subject: Re: [cifs-protocol] [REG:111061069959469] BranchCache and SMB2: > >>> Questions specific to BranchCache. > >>> > >>> Edgar, > >>> > >>> Thanks for the clarifications. > >>> > >>> Regarding the dwOffsetInFirstSegment and dwReadBytesInLastSegment > >>> fields... > >>> > >>> I have a working prototype, written as a CGI script and running under > >>> Apache. It seems to be giving correct results, when compared to a W2K8r2 > >>> server, but I cannot verify that I am correctly generating the Segment > >>> Secret correctly because I do not know the Server Secret generated by the > >>> Windows server. > >>> > >>> I can extract the Windows Server Secret using a netsh command, but the > >>> command encrypts the Server Secret with a password, and I do not know > >>> what algorithm is used to perform the encryption. If I did, I could > >>> decrypt the Server Secret and use it in my test program to verify that I > >>> am generating the hash correctly. > >>> > >>> Do you know where I could find documentation that would tell me what > >>> algorithm is being used to encrypt the extracted Server Secret? > >>> > >>> > >>> > >>> Regarding the glossary definition of "segment secret" in [MS-PCCRC]... > >>> > >>> I would suggest that the use of "authenticated" in the context of the > >>> description of "segment secret" is misleading. [MS-PCCRC] covers a > >>> variety of server types, and in many cases there is no authentication > >>> required. I'm testing using HTTP, for example, and my client is being > >>> given Content Information without performing any sort of authentication. > >>> > >>> The fact that SMB2 requires authentication before providing access to a > >>> content or content information is an aspect of SMB2, not BranchCache. > >>> There is no authorization required by the Peer Content Caching and > >>> Retrieval: > >>> Content Identification protocol itself. > >>> > >>> Thanks. > >>> > >>> See you next week. > >>> > >>> Chris -)----- > >>> > >>> > >>> Edgar Olougouna wrote: > >>>> Chris, > >>>> > >>>> For the question regarding "authorized client", BranchCache considers > >>>> possession of the Content Information data structure to be equivalent to > >>>> possession of data for access control purposes. If a client was able to > >>>> obtain hashes from a file server, we will allow that client to retrieve > >>>> data from peers or the hosted cache server. A file server is expected > >>>> to protect the content information data structure the same way it > >>>> protects actual files. If a file server authenticates and authorizes > >>>> clients before allowing them to read files, it should do the same before > >>>> providing them with hashes. > >>>> > >>>> Yes, your interpretation regarding dwOffsetInFirstSegment and > >>>> dwReadBytesInLastSegment appears to be correct. > >>>> Basically, dwReadBytesInLastSegment is a count of bytes you can read in > >>>> the last segment. If the range is one segment long then the last segment > >>>> is the only segment so dwOffsetInFirstSegment and > >>>> dwReadBytesInLastSegment both apply to it. If the range is multiple > >>>> segments long then dwOffsetInFirstSegment applies to the first segment > >>>> and dwReadBytesInLastSegment applies to the last segment. > >>>> > >>>> In my previous communication, it should be Windows Server 2008 R2 > >>>> instead of Windows 7. Only Windows Server 2008 R2 servers could be > >>>> BranchCache servers, so both OS versions cannot be used interchangeably > >>>> in this case. Thanks for catching this. > >>>> > >>>> Finally, I have passed on your feedback to the product team and > >>>> suggested that an example of range request being added to the document. > >>>> Thanks again for the numerous observations. > >>>> > >>>> Regards, > >>>> Edgar > >>>> > >>>> -----Original Message----- > >>>> From: Edgar Olougouna > >>>> Sent: Friday, June 10, 2011 2:14 PM > >>>> To: 'Christopher R. Hertel' > >>>> Cc: [email protected] > >>>> Subject: RE: [cifs-protocol] [REG:111051857287367] BranchCache and SMB2: > >>>> Questions specific to BranchCache. > >>>> > >>>> Chris, > >>>> > >>>> Thanks for the numerous observations. I will review the questions and > >>>> follow-up as soon as I have an update. > >>>> > >>>> Regards, > >>>> Edgar > >>>> > >>>> -----Original Message----- > >>>> From: Christopher R. Hertel [mailto:[email protected]] > >>>> Sent: Friday, June 10, 2011 12:57 AM > >>>> To: Edgar Olougouna > >>>> Cc: [email protected] > >>>> Subject: Re: [cifs-protocol] [REG:111051857287367] BranchCache and SMB2: > >>>> Questions specific to BranchCache. > >>>> > >>>> Edgar, > >>>> > >>>> One more observation and another quick question: > >>>> > >>>> Question: > >>>> > >>>> The [MS-PCCRC] Glossary (section 1.1) gives the following definition: > >>>> > >>>> segment secret: The content-specific hash that is sent to authorized > >>>> clients along with the rest of the content information. It is > >>>> generated by hashing the concatenation of the segment hash of data > >>>> and the server secret. > >>>> > >>>> What does the phrase "authorized clients" mean? How is a client > >>>> authorized in this context? > >>>> > >>>> Observation: > >>>> Now that I understand the purpose of the dwOffsetInFirstSegment and > >>>> dwReadBytesInLastSegment fields it appears that the descriptions of > >>>> these fields in [MS-PCCRC], though inscrutable, are plausible. > >>>> > >>>> In particular, the following now makes sense: > >>>> > >>>> dwReadBytesInLastSegment (4 bytes): Total number of bytes of the > >>>> content range which lie within the final segment in the Content > >>>> Information data structure. > >>>> > >>>> If the requested range includes multiple segments, then the offset > >>>> of the dwReadBytesInLastSegment bytes to be read is 0, relative to > >>>> the segment. What is interesting to note is that if the requested > >>>> range is included in only ONE segment, then the > >>>> dwReadBytesInLastSegment bytes to be read start at the offset > >>>> indicated by dwOffsetInFirstSegment. > >>>> > >>>> Chris -)----- > >>>> > >>>> > >>>> Christopher R. Hertel wrote: > >>>>> Edgar, > >>>>> > >>>>> Thanks again for this reply. I have some comments which I hope > >>>>> you will pass along to the documentation team and engineers. > >>>>> > >>>>> On Tue, May 31, 2011 at 08:43:22PM +0000, Edgar Olougouna wrote: > >>>>>> Chris, > >>>>>> > >>>>>> Please find our answers as follows. > >>>>>> > >>>>>> BranchCache divides content into 32 megabyte segments and further > >>>>>> subdivides these segments into 64 kilobyte blocks. > >>>>> Yes. [MS-PCCRC] does a good job of explaining that part. > >>>>> > >>>>>> The content information encodes: > >>>>>> (1) ullOffsetInContent - the offset within the content at which > >>>>>> the first segment present in the content information begins and > >>>>> Again yes, this makes sense to me. > >>>>> > >>>>>> (2) dwOffsetInFirstSegment - the offset from ullOffsetInContent > >>>>>> at which the first block of the first segment present in the > >>>>>> content information begins. > >>>>> This is where things get confusing. > >>>>> > >>>>>> Let's walk through this with an example. > >>>>>> Let's assume the client requests a content range starting at > >>>>>> content offset 33554433 (a.k.a. 32 megabytes plus one byte) and > >>>>>> extending for > >>>>>> 10 bytes. > >>>>> Problem #1 (for me): The examples given in the document > >>>>> specifically state that they show requests for entire files. From > >>>>> section 3.1: > >>>>> > >>>>> "A client requests the entirety of the 125 kilobyte content from the > >>>>> server. The server responds with Content Information of the > >>>>> following > >>>>> form." > >>>>> > >>>>> >From section 3.2: > >>>>> > >>>>> "The same server S now receives a client request for a 125-megabyte > >>>>> file." > >>>>> > >>>>> ...so, the examples in [MS-PCCRC] do not cover the use of ranges. > >>>>> These are whole-file requests, so there is no example of how > >>>>> dwOffsetInFirstSegment or dwReadBytesInLastSegment might be used > >>>>> (though there are descriptions). > >>>>> > >>>>>> ullOffsetInContent will be 32 megabytes because that is where the > >>>>>> first segment present in the content information begins. > >>>>> Makes sense. > >>>>> > >>>>>> dwOffsetInFirstSegment will be 1 because the first segment in the > >>>>>> content information is the second segment in the actual content > >>>>>> because the requested content range starts at 32 megabytes plus one. > >>>>> So... If I understand this correctly, the situation is that > >>>>> BranchCache must operate in terms of Segments, and when it returns > >>>>> the Segment Information for this segment, it is including an > >>>>> offset, relative to the start of the Segment, at which the *requested* > >>>>> content begins. > >>>>> > >>>>> Is that correct? > >>>>> > >>>>>> dwReadBytesInLastSegment will be 10 because that is the length of > >>>>>> the content range that lies within the final segment present in > >>>>>> the content information. > >>>>> If my new understanding of dwOffsetInFirstSegment is correct, then > >>>>> I believe that my understanding of dwReadBytesInLastSegment is now > >>>>> also correctly updated. > >>>>> > >>>>> Basically, if the client requests a range the server must send > >>>>> Content Information covering the segments that completely include > >>>>> the requested range. These two values indicate how to handle the > >>>>> cached segments when the client retrieves them from the cache, as > >>>>> follows: > >>>>> > >>>>> dwOffsetInFirstSegment - Discard this many leading bytes of the > >>>>> first > >>>>> segment retrieved from cache. > >>>>> > >>>>> Retain all bytes of all subsequent segments > >>>>> retrieved from cache except the last one. > >>>>> > >>>>> dwReadBytesInLastSegment - Retain only this many leading bytes of the > >>>>> last segment retrieved from cache. > >>>>> > >>>>> Is that correct? > >>>>> > >>>>>> Note that dwReadBytesInLastSegment may be zero if the client did > >>>>>> not request a content range (i.e. the client asked for the entire > >>>>>> content). > >>>>> So a dwReadBytesInLastSegment value of zero is interpreted as "all > >>>>> bytes" > >>>>> in the segment. > >>>>> > >>>>>> The scenarios in which dwReadBytesInLastSegment will be zero are > >>>>>> Windows specific behavior. In Windows 7, this happens whenever > >>>>>> the content information covers the entire content. In order to > >>>>>> participate in the MS-PCCRC protocol, a client must be able to > >>>>>> parse content information that contains a zero value for > >>>>>> dwReadBytesInLastSegment. The client must react by treating the > >>>>>> segment size for the final segment encoded in the content > >>>>>> information as the amount of data in the final segment. If > >>>>>> dwReadBytesInLastSegment is non-zero then the client must only > >>>>>> attempt to read dwReadBytesInLastSegment from the final segment, > >>>>>> regardless of the segment size of the final segment. > >>>>> Not quite... Assuming that I'm catching on here, and that such a > >>>>> bug could happen, the goal would be something like the following: > >>>>> > >>>>> if 0 == dwReadBytesInLastSegment > >>>>> readbytes = cbSegment > >>>>> else > >>>>> readbytes = min( dwReadBytesInLastSegment, cbSegment ) > >>>>> > >>>>> If, due to some bug, the dwReadBytesInLastSegment were greater > >>>>> than the number of actual bytes in the segment then you would > >>>>> still want to read only the number of actual bytes in the segment. > >>>>> I can envision something like this happing if the requested range > >>>>> extended beyond the end of the Content and the server did not clean up > >>>>> the results properly. > >>>>> > >>>>> Okay, so I am being picky here... but it serves to verify whether > >>>>> or not I am understanding these fields. > >>>>> > >>>>>> On Windows 7, if the content fits in one segment and the client > >>>>>> issued a request for the entire content then, > >>>>>> dwReadBytesInLastSegment should be zero and dwOffsetInFirstSegment > >>>>>> should be zero. > >>>>> It was my understanding, based on my reading of a number of > >>>>> several MSDN web pages, that only Windows 2008R2 servers could be > >>>>> BranchCache servers. > >>>>> Windows 7 systems could only be clients. Vista and Windows 2008 > >>>>> systems could also be clients if an additional package was installed. > >>>>> (W2Kr2 servers can also be BranchCache clients, I believe.) > >>>>> > >>>>> The idea that Windows 7 cannot be a BranchCache Server is somewhat > >>>>> supported by the following Windows Behavior note from [MS-PCCRC]: > >>>>> > >>>>> "<2> Section 2.3: In Windows 7, the [MS-PCCRR] implementation can only > >>>>> accept segment IDs generated using SHA-256, whereas the Windows > >>>>> Server > >>>>> 2008 R2 implementation of the hash generation part can generate > >>>>> segment > >>>>> IDs using one of three hashing algorithms: SHA-256, SHA- 384, or > >>>>> SHA-512." > >>>>> > >>>>> Note that the behavior note only talks about Windows 7 in client > >>>>> mode and says nothing about its capabilities in server mode. I > >>>>> believe that's because Windows 7 doesn't support server mode. > >>>>> Also, only a Windows > >>>>> 2008r2 server can act as a hosted cache. Windows 7 clients, I > >>>>> believe, can operate as peer caches. > >>>>> > >>>>> So... Do you mean to say Windows 7 or Windows 2Kr2 in the statement > >>>>> above? > >>>>> If Windows 7, then are you talking about W7 clients sending > >>>>> content requests to the hosted cache server or as broadcasts on the > >>>>> local LAN? > >>>>> If so, that part of BranchCache is outside of the scope of [MS-PCCRC] > >>>>> ... > >>>>> which leaves me confused as to what you are trying to explain to > >>>>> me when you describe Windows 7 behavior. > >>>>> > >>>>>> The product team will be reflecting the above clarification in > >>>>>> the protocol document. Let me know whether this answers your questions. > >>>>> It would be quite helpful if an additional example were presented > >>>>> in order to show how these values are used. I found the > >>>>> descriptions of these values to be difficult to interpret when reading > >>>>> the documentation. > >>>>> > >>>>> Unless you tell me that my understanding, given above, is > >>>>> incorrect I believe that your description has clarified things nicely. > >>>>> > >>>>> Thanks. > >>>>> > >>>>> Chris -)----- > >>>>> > >>>>>> Regards, > >>>>>> Edgar > >>>>>> > >>>>>> -----Original Message----- > >>>>>> From: Edgar Olougouna > >>>>>> Sent: Tuesday, May 31, 2011 11:07 AM > >>>>>> To: 'Christopher R. Hertel' > >>>>>> Cc: [email protected] > >>>>>> Subject: RE: [cifs-protocol] [REG:111051857287367] BranchCache and > >>>>>> SMB2: Questions specific to BranchCache. > >>>>>> > >>>>>> Chris, > >>>>>> > >>>>>> I am actively working on this with the product team to clarify a few > >>>>>> more points. I will update you as soon as possible. > >>>>>> > >>>>>> Regards, > >>>>>> Edgar > >>>>>> > >>>>>> -----Original Message----- > >>>>>> From: Christopher R. Hertel [mailto:[email protected]] > >>>>>> Sent: Sunday, May 29, 2011 5:57 PM > >>>>>> To: Edgar Olougouna > >>>>>> Cc: MSSolve Case Email; [email protected] > >>>>>> Subject: Re: [cifs-protocol] [REG:111051857287367] BranchCache and > >>>>>> SMB2: Questions specific to BranchCache. > >>>>>> > >>>>>> Edgar, > >>>>>> > >>>>>> I am just checking in on this ticket. I understand that the > >>>>>> resolution to these issues can take some time, but I want to test my > >>>>>> implementation at the FileSharing Plugfest in a few weeks time. > >>>>>> Having the answers would help me complete my testing implementation. > >>>>>> > >>>>>> Thanks. > >>>>>> > >>>>>> Chris -)----- > >>>>>> > >>>>>> Obaid Farooqi wrote: > >>>>>>> Hi Chris: > >>>>>>> Thank you for contacting Microsoft regarding your query on branch > >>>>>>> cache. A member of the protocol documentation team will be in touch > >>>>>>> soon. > >>>>>>> > >>>>>>> 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 [email protected] > >>>>>>> > >>>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: Christopher R. Hertel [mailto:[email protected]] > >>>>>>> Sent: Tuesday, May 17, 2011 9:12 PM > >>>>>>> To: Interoperability Documentation Help > >>>>>>> Subject: BranchCache and SMB2: Questions specific to BranchCache. > >>>>>>> > >>>>>>> I have a couple of questions regarding BranchCache and [MS-PCCRC]. > >>>>>>> As you know, BranchCache--particularly the Content Information format > >>>>>>> specified in [MS-PCCRC]--can be used as an extension to SMB2. > >>>>>>> > >>>>>>> 1) In the Content Information structure ([MS-PCCRC:2.3]), there is the > >>>>>>> following field definition: > >>>>>>> > >>>>>>> dwOffsetInFirstSegment (4 bytes): Number of bytes into the first > >>>>>>> segment within the Content Information data structure at which > >>>>>>> the content range begins. > >>>>>>> > >>>>>>> I can't make heads nor tails of that description, and the captures > >>>>>>> I > >>>>>>> have done on the wire typically show that field set to zero. > >>>>>>> Similarly, the examples in section 3 of [MS-PCCRC] show the value > >>>>>>> of > >>>>>>> this field to be zero. > >>>>>>> > >>>>>>> The field is 4 bytes in length, so it cannot be an offset into the > >>>>>>> content itself, since content offsets are (should be) 8 bytes > >>>>>>> (64-bit). > >>>>>>> > >>>>>>> Please clarify: What does dwOffsetInFirstSegment actually > >>>>>>> represent? > >>>>>>> > >>>>>>> 2) I am not getting what I expect in the dwReadBytesInLastSegment > >>>>>>> field. > >>>>>>> This field is defined in [MS-PCCRC:2.3], as follows: > >>>>>>> > >>>>>>> dwReadBytesInLastSegment (4 bytes): Total number of bytes of the > >>>>>>> content range which lie within the final segment in the Content > >>>>>>> Information data structure. > >>>>>>> > >>>>>>> It seems to me that this value represents the number of bytes > >>>>>>> of actual content included in the calculation of the final > >>>>>>> Segment block of the Content Information. That interpretation > >>>>>>> is supported by the examples in section 3. > >>>>>>> > >>>>>>> In actual captures, however, Windows IIS server returns zero > >>>>>>> (0x00000000) in the dwReadBytesInLastSegment field. > >>>>>>> > >>>>>>> Is this a documentation bug or is the IIS server returning the > >>>>>>> wrong value? > >>>>>>> > >>>>>>> This is IIS running on W2K8r2 with fairly up-to-date patches > >>>>>>> applied. > >>>>>>> > >>>>>>> Looking forward to the replies. > >>>>>>> > >>>>>>> Thanks. > >>>>>>> > >>>>>>> Chris -)----- > >>>>>>> > >>>>>>> -- > >>>>>>> "Implementing CIFS - the Common Internet FileSystem" ISBN: 013047116X > >>>>>>> Samba Team -- http://www.samba.org/ -)----- Christopher R. > >>>>>>> Hertel > >>>>>>> jCIFS Team -- http://jcifs.samba.org/ -)----- ubiqx development, > >>>>>>> uninq. > >>>>>>> ubiqx Team -- http://www.ubiqx.org/ -)----- [email protected] > >>>>>>> OnLineBook -- http://ubiqx.org/cifs/ -)----- [email protected] > >>>>>>> > >>>>>> -- > >>>>>> Christopher R. Hertel -)----- Storage Architect & CIFS Geek > >>>>>> http://www.ubiqx.com/ Data Storage and Systems Consulting > >>>>>> "Implementing CIFS - the Common Internet FileSystem" ISBN: 013047116X > >>>>>> > > > > -- > "Implementing CIFS - the Common Internet FileSystem" ISBN: 013047116X > Samba Team -- http://www.samba.org/ -)----- Christopher R. Hertel > jCIFS Team -- http://jcifs.samba.org/ -)----- ubiqx development, uninq. > ubiqx Team -- http://www.ubiqx.org/ -)----- [email protected] > OnLineBook -- http://ubiqx.org/cifs/ -)----- [email protected] > _______________________________________________ cifs-protocol mailing list [email protected] https://lists.samba.org/mailman/listinfo/cifs-protocol
