[cifs-protocol] RE: erroneous references to little-endian
abartlet at samba.org
Mon Jun 29 04:55:36 GMT 2009
On Fri, 2009-06-19 at 07:40 -0700, Richard Guthrie wrote:
> I wanted to confirm that the information below resolves your issue. If I don't hear from you by Wednesday of next week I will go ahead and archive this issue.
No, it doesn't. In short, this still feels like a complete mess, and is
only made worse by the tables.
> Thank you for the feedback. In Section 220.127.116.11, the
> NETLOGON_NT_VERSION options bit table is indeed presented in
> little-endian byte ordering with the lowest order byte being
> represented by bits 0-7, the next higher byte represented by bits 8-15
> and so on. Therefore the claim that the bit table is presented in
> little-endian format is correct. We have verified this for other bit
> fields in [MS-ADTS] as well. The explicit specification of whether the
> bytes are ordered in little-endian or big endian format is intended to
> clarify the relative position of the bytes in a multi-byte bit flag.
Ahh, so the table is self-contradictory and even more useless than
normal. I should have remembered, as this was one of the most annoying
things I found when first going over this area.
It is *never* valid to present bits in a different order to the bytes.
> The NETLOGON_NT_VERSION options is not represented as an integer
> string over LDAP. It may appear in the LDAP search filter of an LDAP
> ping (Section 7.3.3) as a binary encoded value or it appears in an
> LDAP response to an LDAP ping (Section 18.104.22.168) where it is packed as
> part of one of the following (in little-endian format):
> NETLOGON_PRIMARY_RESPONSE (described in Section 22.214.171.124),
> NETLOGON_SAM_LOGON_RESPONSE_NT40 (Section 126.96.36.199),
> NETLOGON_SAM_LOGON_RESPONSE (Section 188.8.131.52), or
> NETLOGON_SAM_LOGON_RESPONSE_EX (Section 184.108.40.206). Please let us know
> if you have any further questions/feedback.
I think this is an excellent example of why this documentation fails
spectacularly to communicate these issues, and presents the least
implementable formation for the bit-fields it attempts to describe.
Is is ever actually useful to list bits with a value such that the bit
cannot be represented on the network with the calculation of 2^n = bit
Authentication Developer, Samba Team http://samba.org
Samba Developer, Red Hat Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/cifs-protocol/attachments/20090629/74f8adce/attachment.bin
More information about the cifs-protocol