web-dev-qa-db-ja.com

イーサネットCRC32計算-ソフトウェアとアルゴリズムの結果

イーサネットパケットのフレームチェックシーケンス（FCS）をバイトごとに計算しようとしています。多項式は0x104C11DB7です。ここで見られるXOR-SHIFTアルゴリズムに従いました http://en.wikipedia.org/wiki/Cyclic_redundancy_check またはここ http://www.woodmann.com/fravia/crctut1。 htm

CRCがあると想定される情報は1バイトだけであると想定します。 0x03だとしましょう。

  1. ステップ：右側に32ビットのパッド

    0x0300000000

  2. 左側の多項式とデータをゼロではない最初のビットに揃えて、それらを排他的論理和します

    0x300000000 xor 0x209823B6E = 0x109823b6e

  3. 残りを揃えてxorをもう一度

    0x109823b6e xor 0x104C11DB7 = 0x0d4326d9

残りのビットがないため、0x03のCRC32は0x0d4326d9である必要があります。

残念ながら、すべてのソフトウェア実装は私が間違っていると言っていますが、私は何を間違ったのですか、それとも彼らは何が違うのですか？

Pythonは私に言います：

 "0x%08x" % binascii.crc32(chr(0x03))
 0x4b0bbe37

ここのオンラインツール http://www.lammertbies.nl/comm/info/crc-calculation.html#intr 同じ結果が得られます。私の手の計算と前述のソフトウェアが使用するアルゴリズムの違いは何ですか？

更新：

スタックオーバーフローですでに同様の質問があったことが判明しました：

ここで答えが見つかります Python CRC-32の問題

これはあまり直感的ではありませんが。イーサネットフレームに対してどのように行われるかについてより正式な説明が必要な場合は、 イーサネット標準ドキュメント802. パート3-第3.2.9章フレームチェックシーケンスフィールドを参照してください。

上から例を続けましょう：

  1. メッセージのビット順序を逆にします。それは彼らが少しずつ受信機に入る方法を表しています。

    したがって、0x03は0xC0です。

  2. メッセージの最初の32ビットを補完します。 1バイトを再び32ビットで埋めていることに注意してください。

    0xC000000000 xor 0xFFFFFFFF = 0x3FFFFFFF00

  3. Xorとshiftメソッドを上からもう一度完了します。約6ステップ後、次のようになります。

    0x13822f2d

  4. 次に、上記のビットシーケンスが補完されます。

    0x13822f2d xor 0xFFFFFFFF = 0xec7dd0d2

  5. ステップ1でイーサネットワイヤの表現を取得するためにビット順序を逆にしたことを思い出してください。今、私たちはこのステップを逆にする必要があり、最終的に私たちの探求を果たします。

    0x4b0bbe37

この方法を思いついた人は誰でも...

多くの場合、実際に受信したメッセージが正しいことを知りたいと思うでしょう。これを実現するには、FCSを含む受信メッセージを受け取り、上記と同じ手順1〜5を実行します。結果は、彼らが残留物と呼ぶものになるはずです。これは、与えられた多項式の定数です。この場合は0xC704DD7Bです。

mcdowellaが述べているように、使用しているアプリケーションに応じて、正しくなるまでビットをいじる必要があります。

pythonalgorithmethernetcrc32
13
sebs

このスニペットは、イーサネットの正しいCRCを書き込みます。

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)

ここでこれを見つけたら、時間を節約できただろう。

8
maxy

実行する必要のあることを正確に読み取ることは決してないため、CRC計算を一致させるには、一般に少し試行錯誤が必要です。入力バイトまたは多項式をビットリバースする必要がある場合もあれば、ゼロ以外の値から開始する必要がある場合もあります。

これを回避する1つの方法は、プログラムのソースを調べて正しく処理することです。たとえば、 http://sourceforge.net/projects/crcmod/files/ （少なくとも一致すると主張し、このためのユニットテストが付属しています）。

もう1つは、実装をいじることです。たとえば、 http://www.lammertbies.nl/comm/info/crc-calculation.html#intr で計算機を使用すると、00000000を指定すると0x2144DF1CのCRCが生成されることがわかります。ただし、FFFFFFFFを指定すると、FFFFFFFFが生成されます。したがって、これは、説明する多項式の除算ではなく、0のチェックサムは0になります。

ソースコードとこれらの結果を一目見ただけで、0xFFFFFFFFのCRCから始める必要があると思います-しかし、私は間違っている可能性があり、対応するprintfsを使用してコードを実装と並行してデバッグし、場所を見つける可能性があります最初は異なり、違いを1つずつ修正します。

4
mcdowella

インターネット上には、FCSを計算する前にビットの順序を逆にする必要があることを読む場所がたくさんありますが、802.3仕様はその1つではありません。仕様の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.
3
Daniel Wisehart

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

イーサネットのすべてのデータと豊富な重要な詳細があります。たとえば、多項式を32ビット値にエンコードするための（少なくとも）2つの規則があり、最大項が最初または最小項が最初です。

2
Dima Tisnek