SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    iSCSI CRC inconsistency



    Julian,
    
    There is an inconsistency in the description of the CRC32. In 11.1, the final paragraph on page 207 is incorrect. The paragraph says:
    - The CRC bits appear after the message bits with x^31 first
    followed by x^30 etc. (when examples are provided, the value
    to be specified in the examples follows the same
    ordering as the rest of this document).
    
    At the top of the next page, it describes the magic number CRC check where one runs the CRC generator over the data or header plus the received digest and gets the magic number:
    - A receiver of a "good" segment (data or header) including the
    CRC built using the generator 0x11edc6f41 will get the value
    0x1c2d19ed as its CRC (this is a polynomial value and not a
    word as outlined in this draft).
    
    The point of the magic number algorithm is that it uses exactly the same algorithm to check the CRC that was used to generate the CRC. When running the check, the received CRC is run through the generator with the same bit order as the covered data. Therefore, this check only works right when the CRC is appended to the data using the same bit ordering within a word as was used when sending the covered data through the CRC generator. The examples in B.4 show the bits ordered as they should be and page 207 is inconsistent with them..
    
    Specifically, data bits go through the generator from byte 0 to byte 3 of the word with each bit going through bit 7 to bit 0. Therefore, paragraph on how the CRC bits are placed in the field should be:
    - The CRC bits appear after the message bits with the x^31 coefficient in bit 7 of the first byte (byte 0) of the digest continuing to through the byte the x^24 coefficient in bit 0 of byte 0, continuing with the x^23 coefficient in bit 7 of byte 1, etc. (When examples are provided they show the CRC as it appears in the PDU with the bit significance used throughout this document. That is, bit 7 of each byte is interpreted as most significant though it is the coefficient of the lowest order CRC term in the byte.).
    
    I have checked and this order matches the examples in B.4.
    
    Regards,
    Pat
    


Home

Last updated: Wed Jun 05 14:18:33 2002
10519 messages in chronological order