0

假设示例... CRC 附加到末尾的缓冲区的 CRC 是否始终为 0？

extern uint16_t CRC16(uint_8* buffer, uint16_t size);  // From your favorite library

void main() {
   uint16_t crc; 
   uint8_t buffer[10] = {1,2,3,4,5,6,7,8};

   crc = CRC16(buffer,8);

   buffer[8]= crc>>8;      // This may be endian-dependent code
   buffer[9]= crc & 0xff;  // Ibid.

   if (CRC16(buffer,10) != 0) 
    printf("Should this ever happen???\n");
   else
    printf("It never happens!\n");

}
4

2 回答 2

3

如果 CRC 在计算后被修改，例如某些 CRC 在生成 CRC 后对 CRC 进行补充，则使用数据 + 附加 CRC 生成新的 CRC 将导致非零但恒定的值。如果 CRC 没有后修改，则结果将为零，无论 CRC 在生成之前是否被初始化为零或非零值。

于 2020-03-17T10:15:48.127 回答
0

将 CRC 附加到末尾的缓冲区的 CRC 始终为 0 是否总是正确的？

取决于 CRC，以及它是如何附加的。对于网络中使用的 16 位和 32 位 CRC “CCITT”（以太网，V42..），否：最终 CRC（按指定顺序附加）是一个常数，但不为零：47 0F对于 16 位 CRC ，1C DF 44 21对于 32 位 CRC。16 位示例

-------- message --------            CRC-CCITT-16
01 02 03 04 05 06 07 08                 D4 6D
01 02 03 04 05 06 07 08  D4 6D          47 0F
DE AD BE EF                             CB E5
DE AD BE EF  CB E5                      47 0F

这在电信中很方便，处理接收的层通常知道帧仅在接收到 CRC 后才结束，该 CRC 已经输入到硬件中检查 CRC。

根本原因是 8 字节消息的 16 位 CRC被生成多项式m0 m1 … m6 m7定义为序列的余数。 当我们计算后跟原始 CRC 的消息的 CRC时，新的 CRC 因此是生成多项式的序列的余数，因此是生成多项式的序列的余数，因此是一个常数，但没有理由为零。/m0 /m1 m2 m3 … m6 m7 FF FF
r0 r1/m0 /m1 m2 m3 … m6 m7 r0 r1 FF FFFF FF FF FF

在 Python 中在线尝试！. 包括 16 位和 32 位，“手动”并使用外部库，包括常数为零的库。

对于未附加正确位数或输出 CRC 错误字节序的 CRC（这些变体很多），结果取决于消息。这是出现问题的明确信号，并且相应地

  • 接收方不能再将消息的 CRC 输入 CRC 检查器并将结果与​​常数进行比较以检查消息的完整性。
  • 它丢失了 CRC 的理想属性，即任何集中在不超过 CRC 的位序列上的错误都被捕获（如果我们没有直接得到 CRC，则与消息末尾重叠的错误和 CRC 有时会保留未被发现）
于 2020-03-18T09:08:20.913 回答