Как получить rnet магический номер 0xC704DD7B из калькулятора zlib crc32 - PullRequest
Новая
       138

Как получить rnet магический номер 0xC704DD7B из калькулятора zlib crc32

0 голосов
/ 28 января 2020

Я взял фрагмент python из этого ответа (слегка измененный) для вычисления контрольной последовательности кадра rnet crc32: 

msg = '00'
data = bytes.fromhex(msg)
print(data)
print(msg)
crc = zlib.crc32(data)&0xFFFFFFFF
for i in range(4):
    b = (crc >> (8*i)) & 0xFF
    print('{:02X}'.format(b))

Для сообщения 00 он выводит 8D EF 02 D2, что является решением для обратного бита из этого ответа . Пока все хорошо.

Теперь сказано здесь , что

Запуск алгоритма CR C для полученных данных кадра, включая CR C код всегда будет приводить к нулевому значению для безошибочных полученных данных, потому что CR C является остатком данных, разделенным на полином. Однако этот метод может не обнаружить ошибки, в которых данные с конечными нулями также приводят к тому же нулевому остатку. Чтобы избежать этого сценария, FCS дополняется (каждый бит отменяется) отправителем, прежде чем он присоединяется к концу данных полезной нагрузки. Таким образом, результат алгоритма всегда будет остатком CRC32 0xC704DD7B, когда данные были получены правильно.

Но если я введу 00 8D EF 02 D2 в калькулятор, результат будет 1C DF 44 21, а не указанный остаток. Я также пробовал другие комбинации, потому что часто биты в байтах должны быть обращены или что-то в этом роде (на самом деле я действительно запутался во всех этих вещах обратного хода, но я надеялся, что хороший результат после испытания нескольких возможностей приведет меня к правильному обращению), но безуспешно: 

00 D8 FE 20 2D -> 66 40 C3 4A
00 D2 02 EF 8D -> DF 42 14 03
00 2D 20 FE D8 -> CB 50 00 AE

Итак, кто-нибудь может сказать мне, где я не прав?

1 Ответ

2 голосов
/ 28 января 2020

0xC704DD7B, который был в статье Wiki, является инвертированным битом и дополнением 0x2144DF1 C, которое является значением, которое вы получаете, и значением, которое вы должны получить.

В случае CRC32, так как CR C дополняется после публикации, «хороший» пересчет CR C, выполняемый для данных + ранее вычисленный CR C, будет ненулевой константой, в данном случае 0x2144DF1 C. Это не «число магов c», ненулевое значение константы для хорошего CR C является следствием посткомплементации CR C (в противном случае хороший пересчитанный CR C будет равен нулю).

Что сбивает с толку, так это то, что стандарт IEEE использует CRC32 BZIP2 со сдвигом влево (не обращенный) CR C для создания CR C, а затем сообщает, что данные сначала передаются младшим значащим битом, в то время как CR C (называемый FCS (Frame Check Sequence)) передается первым старшим значащим битом (бит 31). При использовании правого сдвига CRC32 (в обратном порядке) CR C производит тот же CR C, но с обращенным битом, и передача как данных, так и самого младшего значащего бита CR C приводит к идентичной передаче. Таким образом, в зависимости от фактической реализации, CR C может быть обращен или нет, и может дополняться или не дополняться, если используется «остаток» в аппаратном регистре.

Теперь статья в вики обновлена ​​и теперь включает эти проблемы.

...