Всегда ли верно, что CR C буфера, к которому добавлен конец CR C, всегда равен 0? - PullRequest
Новая
       119

Всегда ли верно, что CR C буфера, к которому добавлен конец CR C, всегда равен 0?

0 голосов
/ 16 марта 2020

Пример гипотезы ... Всегда ли верно, что CR C буфера с добавленным в конец CR C всегда равен 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");

}

Ответы [ 2 ]

2 голосов
/ 17 марта 2020

Если CR C изменяется после его вычисления, например, некоторые CRC, которые публикуют CR C после его генерации, то генерация нового CR C с использованием данных + добавленного CR C приведет к ненулевое, но постоянное значение. Если CR C не является пост-модифицированным, то результат будет нулевым, независимо от того, инициализируется ли CR C нулевым или ненулевым значением перед генерацией.

0 голосов
/ 18 марта 2020

Всегда ли верно, что CR C буфера, к которому добавлен CR C, всегда равен 0?

Зависит от CR C и как это добавляется. Для 16-битного и 32-битного CR C "CCITT", используемого в сети (Ethe rnet, V42 ..), no : конечный CR C (добавляется в указанном порядке ) - это константа , но не ноль: 47 0F для 16-битного CR C, 1C DF 44 21 для 32-битного CR C. 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

Это удобно в телекоммуникациях, где часто получатель, обрабатывающий уровни, знает, что кадр заканчивается только после получения CR C, который уже был введен в аппаратном обеспечении, проверяющем CR C.

Основная причина заключается в том, что 16-битный CR C 8-байтового сообщения m0 m1 … m6 m7 определяется как остаток последовательности /m0 /m1 m2 m3 … m6 m7 FF FF порождающим полиномом.
Когда мы вычисляем CR C сообщения, за которым следует исходный CR C r0 r1, новый CR C, таким образом, является остатком последовательности /m0 /m1 m2 m3 … m6 m7 r0 r1 FF FF генерирующим полиномом и, следовательно, остатком от последовательность FF FF FF FF производящим полиномом, то есть константой, но не имеет оснований быть равной нулю.

Попробуйте онлайн в Python! . Включает 16-битную и 32-битную "вручную" и использует внешнюю библиотеку, в том числе библиотеку, в которой константа равна нулю.

Для CRC, которые не добавляют правильное количество бит или выводят CR C неправильный (эти варианты - легион), результат зависит от сообщения. Это верный признак того, что что-то не так, и соответственно

  • получатель больше не может вводить CR C сообщения в средство проверки CR C и сравнивать результат с константой для проверки. целостность сообщения.
  • теряется желаемое свойство CR C, что любая ошибка, сконцентрированная на последовательности битов не длиннее CR C, перехватывается (если мы не получим CR C прямо, ошибка, которая перекрывает конец сообщения и CR C может когда-нибудь остаться незамеченной)
...