Расчет Ethernet CRC32 - программное против алгоритмического результата

Этот фрагмент записывает правильный CRC для Ethernet.

Python 3

# write payload
for byte in data:
    f.write(f'{byte:02X}\n')
# write FCS
crc = zlib.crc32(data) & 0xFFFF_FFFF
for i in range(4):
    byte = (crc >> (8*i)) & 0xFF
    f.write(f'{byte:02X}\n')

Python 2

# write payload
for byte in data:
    f.write('%02X\n' % ord(byte))
# write FCS
crc = zlib.crc32(data) & 0xFFFFFFFF
for i in range(4):
    byte = (crc >> (8*i)) & 0xFF
    f.write('%02X\n' % byte)

Сэкономил бы мне время, если бы нашел это здесь.

Как правило, требуется немного проб и ошибок, чтобы привести вычисления CRC в соответствие, потому что вы никогда не прочитаете, что именно нужно делать. Иногда вам нужно перевернуть входные байты или полином, иногда вам нужно начать с ненулевого значения и так далее.

Один из способов обойти это - посмотреть на исходный код программы, исправивший все, например http://sourceforge.net/projects/crcmod/files/ (по крайней мере, он утверждает, что соответствует, и поставляется с модульным тестом для этого).

Другой - поиграться с реализацией. Например, если я использую калькулятор по адресу http://www.lammertbies.nl/comm/info/crc-calculation.html#intr Я вижу, что если указать 00000000, CRC будет равен 0x2144DF1C, но если дать ему FFFFFFFF, получится FFFFFFFF - так что это не совсем то полиномиальное деление, которое вы описываете, для которого 0 будет иметь контрольную сумму 0

Беглый взгляд на исходный код и эти результаты, я думаю, вам нужно начать с CRC 0xFFFFFFFF, но я могу ошибаться, и вы можете в конечном итоге отладить свой код вместе с реализацией, используя соответствующие printfs, чтобы узнать, где первые различаются и исправляют различия одно за другим.

В Интернете есть ряд мест, где вы прочитаете, что порядок битов должен быть изменен на обратный перед вычислением FCS, но спецификация 802.3 не входит в их число. Цитата из версии спецификации 2008 года:

3.2.9 Frame Check Sequence (FCS) field

A cyclic redundancy check (CRC) is used by the transmit and receive algorithms to
generate a CRC value for the FCS field. The FCS field contains a 4-octet (32-bit)
CRC value. This value is computed as a function of the contents of the protected
fields of the MAC frame: the Destination Address, Source Address, Length/ Type 
field, MAC Client Data, and Pad (that is, all fields except FCS). The encoding is
defined by the following generating polynomial.

  G(x) = x32 + x26 + x23 + x22 + x16 + x12 + x11 
             + x10 + x8 + x7 + x5 + x4 + x2 + x + 1

Mathematically, the CRC value corresponding to a given MAC frame is defined by 
the following procedure:

a) The first 32 bits of the frame are complemented.
b) The n bits of the protected fields are then considered to be the coefficients
   of a polynomial M(x) of degree n – 1. (The first bit of the Destination Address
   field corresponds to the x(n–1) term and the last bit of the MAC Client Data 
   field (or Pad field if present) corresponds to the x0 term.)
c) M(x) is multiplied by x32 and divided by G(x), producing a remainder R(x) of
   degree ≤ 31.
d) The coefficients of R(x) are considered to be a 32-bit sequence.
e) The bit sequence is complemented and the result is the CRC.

The 32 bits of the CRC value are placed in the FCS field so that the x31 term is
the left-most bit of the first octet, and the x0 term is the right most bit of the
last octet. (The bits of the CRC are thus transmitted in the order x31, x30,..., 
x1, x0.) See Hammond, et al. [B37].

Конечно, остальные биты в кадре передаются в обратном порядке, но это не включает FCS. Опять же из спецификации:

3.3 Order of bit transmission

Each octet of the MAC frame, with the exception of the FCS, is transmitted least
significant bit first.

http://en.wikipedia.org/wiki/Cyclic_redundancy_check

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