Skip to content
오늘을살자
Go back

Ethernet FCS byte order가 거꾸로 보이는 이유: CRC-32 값과 실제 전송 순서

Edit page

Ethernet CRC를 처음 직접 계산해보면 가장 많이 헷갈리는 부분이 있다.

계산기는 CRC 값을 이렇게 보여준다.

CRC-32 value: 0xCBF43926

그런데 Ethernet frame 끝에 붙는 FCS byte는 이렇게 보인다.

26 39 F4 CB

처음 보면 값이 거꾸로 뒤집힌 것처럼 보인다.

이 글은 이 차이를 짧게 정리하는 글이다.

CRC 값과 FCS byte는 보는 단위가 다르다

0xCBF43926은 32-bit 숫자처럼 표현한 값이다.

반면 Ethernet frame에 붙는 FCS는 4개의 octet이다.

CRC word view:
  0xCBF43926

FCS bytes on wire:
  26 39 F4 CB

즉 하나는 사람이 보기 좋은 32-bit hex word이고, 다른 하나는 실제 frame trailer에 붙는 byte sequence다.

여기서 발생하는 착시가 “CRC 값이 뒤집혔다”는 느낌이다.

Ethernet FCS는 least-significant byte first로 붙는다

Ethernet FCS는 계산된 32-bit CRC 값을 frame 끝에 4바이트로 붙인다.

이때 byte 순서는 least-significant-byte-first로 보면 된다.

CRC value:
  0xCBF43926

Split into bytes:
  CB F4 39 26

Ethernet FCS order:
  26 39 F4 CB

그래서 CRC 계산 결과를 그대로 big-endian byte 배열처럼 붙이면 테스트가 실패한다.

직접 frame generator, FPGA testbench, Ethernet MAC 검증 코드를 만들 때 특히 자주 나오는 실수다.

기준 예제: 123456789

CRC 구현을 검증할 때 흔히 쓰는 입력이 문자열 123456789다.

ASCII byte로 보면 다음과 같다.

31 32 33 34 35 36 37 38 39

Ethernet CRC-32 파라미터로 계산하면 결과는 다음이다.

CRC-32 value: 0xCBF43926
FCS bytes on wire: 26 39 F4 CB

이 값은 CRC 구현을 검증할 때 좋은 출발점이다.

내 코드가 0xCBF43926을 만들고 있는데 frame validation에서 실패한다면, 다음으로 볼 것은 CRC 알고리즘 자체보다 FCS를 붙이는 byte order일 가능성이 높다.

Ethernet CRC 계산 범위

FCS byte order만큼 많이 틀리는 부분이 계산 범위다.

Ethernet FCS는 보통 다음 범위를 대상으로 계산한다.

포함:
  destination MAC
  source MAC
  EtherType 또는 length
  payload
  padding

제외:
  preamble
  SFD
  inter-frame gap
  FCS 자체

즉 physical layer에서 보이는 모든 bit를 통째로 넣는 게 아니다.

일반적인 raw Ethernet frame byte를 만들 때는 destination MAC부터 시작해서 payload/padding까지 넣고 CRC를 계산한 뒤, 마지막에 FCS 4바이트를 붙이면 된다.

간단한 예제 frame

아래처럼 짧은 Ethernet frame byte가 있다고 하자.

FF FF FF FF FF FF 00 11 22 33 44 55 08 00
45 00 00 2E 00 01 00 00 40 11 7C C9 C0 A8 01 64 C0 A8 01 01

이 byte들에 대해 CRC를 계산하면 다음처럼 볼 수 있다.

CRC-32 value: 0x4A132CA5
FCS bytes on wire: A5 2C 13 4A

frame 끝에 붙일 값은 0x4A132CA5라는 문자열이 아니라 A5 2C 13 4A byte sequence다.

디버깅할 때의 체크 순서

Ethernet CRC가 안 맞을 때는 아래 순서로 확인하면 삽질이 줄어든다.

  1. CRC variant가 Ethernet 방식인지 확인한다.
  2. initial value가 0xFFFFFFFF인지 확인한다.
  3. final XOR가 0xFFFFFFFF인지 확인한다.
  4. reflected input/output 처리가 맞는지 확인한다.
  5. 계산 범위에 preamble, SFD, FCS를 넣지 않았는지 확인한다.
  6. 마지막에 붙인 FCS byte order가 little-endian 형태인지 확인한다.

CRC 값이 맞는데도 frame trailer가 다르게 보이는 문제는 대개 5번이나 6번에서 나온다.

빠르게 확인하는 방법

직접 계산하기 번거롭다면 Ethernet CRC and FCS Calculator에 hex byte를 붙여 넣으면 된다.

도구는 CRC-32 valueFCS bytes on wire를 따로 보여준다.

그래서 구현 코드가 반환한 32-bit 값과 실제 frame 끝에 붙여야 할 4바이트를 바로 비교하기 좋다.

한 줄 요약

Ethernet CRC 값 0xCBF43926과 FCS byte 26 39 F4 CB는 서로 다른 값이 아니라, 같은 CRC를 32-bit word와 실제 wire byte order로 다르게 본 표현이다.


Edit page
Share this post on:

Previous Post
Wireshark에서 Ethernet FCS가 안 보이는 이유: CRC는 어디로 갔을까
Next Post
Ethernet CRC and FCS Calculator, 프레임 체크 시퀀스 계산하기