Ethernet frame을 직접 만들거나 캡처한 raw frame을 확인할 때 헷갈리는 지점이 하나 있습니다.
CRC-32 값 자체보다도, frame 끝에 실제로 붙는 FCS(Frame Check Sequence) 4바이트의 순서입니다.
계산 결과는 0xCBF43926처럼 보이는데 wire에 붙는 값은 26 39 F4 CB처럼 보이기 때문에, 구현이나 테스트 벡터를 맞출 때 “내 계산이 틀린 건가?” 하는 순간이 자주 생깁니다.
이 흐름을 빠르게 확인하기 위해 만든 도구가 Ethernet CRC and FCS Calculator입니다.
어떤 도구인가
Ethernet CRC and FCS Calculator는 입력한 frame byte에 대해 Ethernet 방식의 CRC-32를 계산하고, 실제 frame trailer에 붙는 FCS byte를 함께 보여줍니다.
주요 기능은 이렇습니다.
- Ethernet CRC-32 계산
- FCS bytes on wire 표시
- big-endian view와 wire order 비교
- hex bytes 입력
- UTF-8 text 입력
- trailing FCS validation
- byte preview
- copy FCS
계산은 브라우저 안에서 처리합니다.
Frame byte를 서버로 업로드하지 않기 때문에, 테스트용 패킷이나 내부 payload를 붙여 넣어도 외부 API로 전송되지 않습니다.
Ethernet CRC 파라미터
도구에서 사용하는 값은 일반적인 Ethernet FCS 계산 방식입니다.
Algorithm: CRC-32
Polynomial: 0x04C11DB7
Reflected polynomial: 0xEDB88320
Initial value: 0xFFFFFFFF
Final XOR: 0xFFFFFFFF
Input/output: reflected
CRC-32라는 이름만 같아도 variant가 다르면 결과가 달라집니다.
그래서 Ethernet frame을 확인할 때는 단순히 “CRC32 계산기”를 찾는 것보다 init value, final XOR, reflected 처리, byte order를 같이 확인하는 편이 안전합니다.
기본 사용법
가장 많이 쓰는 흐름은 단순합니다.
Hex bytes모드에서 frame bytes를 붙여 넣습니다.- FCS를 제외한 destination MAC부터 payload/padding까지 입력합니다.
CRC-32 value를 확인합니다.- 실제 frame 끝에 붙일 값은
FCS bytes on wire를 확인합니다. - 필요한 경우
Copy FCS로 4바이트를 복사합니다.
입력은 공백으로 나눈 hex byte뿐 아니라 0x prefix, comma, colon, 연속 hex string도 처리하도록 만들었습니다.
예를 들어 아래처럼 입력해도 됩니다.
FF FF FF FF FF FF 00 11 22 33 44 55 08 00
또는 MAC 주소처럼 colon을 섞은 형태도 파서가 hex digit만 정리해 계산합니다.
예제 1: 표준 테스트 벡터 확인
CRC 구현을 검증할 때 가장 흔히 쓰는 입력은 문자열 123456789입니다.
도구에서 Text 모드로 바꾸고 아래 값을 넣습니다.
123456789
결과는 다음과 같습니다.
CRC-32 value: 0xCBF43926
FCS bytes on wire: 26 39 F4 CB
여기서 중요한 포인트는 0xCBF43926을 그대로 CB F4 39 26으로 붙이는 것이 아니라는 점입니다.
Ethernet FCS octet은 least-significant-byte-first 순서로 frame 끝에 붙기 때문에, wire에서 보는 순서는 26 39 F4 CB가 됩니다.
예제 2: 간단한 frame byte 계산
다음은 broadcast destination, 임의 source MAC, IPv4 EtherType, 짧은 IPv4 header fragment를 넣은 예시입니다.
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
도구에서 계산하면 다음 값을 확인할 수 있습니다.
CRC-32 value: 0x4A132CA5
FCS bytes on wire: A5 2C 13 4A
직접 frame generator나 FPGA testbench, 네트워크 드라이버 테스트 코드를 만들 때는 보통 A5 2C 13 4A처럼 wire order로 붙이는 값이 필요합니다.
반대로 로그나 디버거에서는 0x4A132CA5처럼 32-bit word로 보이는 경우가 있어, 두 표현을 같이 보는 것이 좋습니다.
예제 3: captured frame trailer 검증
캡처한 데이터 끝에 FCS 4바이트가 포함되어 있다면 Input includes trailing FCS 옵션을 켭니다.
예를 들어 text vector 123456789를 hex로 쓰면 다음과 같습니다.
31 32 33 34 35 36 37 38 39
여기에 FCS를 붙인 captured frame 형태는 다음처럼 볼 수 있습니다.
31 32 33 34 35 36 37 38 39 26 39 F4 CB
이 상태에서 trailing FCS 옵션을 켜면, 마지막 4바이트를 captured FCS로 분리하고 앞의 byte들만 다시 CRC 계산합니다.
계산된 expected FCS와 captured FCS가 같으면 FCS matches로 표시됩니다.
무엇을 포함해서 계산해야 하나
Ethernet FCS는 frame 전체를 아무거나 다 넣고 계산하는 값이 아닙니다.
일반적으로 계산 범위는 다음과 같이 보는 것이 안전합니다.
- 포함: destination MAC
- 포함: source MAC
- 포함: EtherType 또는 length
- 포함: payload
- 포함: 필요한 경우 padding
- 제외: preamble
- 제외: SFD
- 제외: inter-frame gap
- 제외: FCS 자체
단, 검증 모드에서는 입력 마지막 4바이트를 captured FCS로 간주하기 때문에 frame bytes 뒤에 FCS까지 붙여 넣을 수 있습니다.
Wireshark에서 FCS가 안 보이는 이유
실무에서 캡처 파일을 보면 FCS가 없는 경우가 많습니다.
대부분의 NIC나 드라이버가 FCS를 하드웨어에서 처리하고, OS로 올릴 때는 frame trailer를 제거하기 때문입니다.
그래서 Wireshark에서 보이는 packet byte만으로 “캡처에 FCS가 없다”고 당황할 필요는 없습니다.
FCS까지 보고 싶다면 사용하는 NIC, driver, capture 옵션이 FCS capture를 지원하는지 별도로 확인해야 합니다.
이런 상황에 잘 맞다
- Ethernet frame generator 테스트
- FPGA/RTL Ethernet MAC 검증
- bootloader나 diagnostic transport의 raw frame 실험
- NIC driver bring-up 중 CRC/FCS byte order 확인
- 캡처한 frame trailer가 맞는지 빠르게 비교
- CRC-32 구현의 test vector 확인
특히 “CRC 값은 맞는 것 같은데 붙이는 byte 순서가 이상하다”는 상황에서 빠르게 기준점을 잡는 용도로 좋습니다.
주의할 점
CRC는 암호학적 hash가 아닙니다.
전송 중 우연히 발생한 bit error를 잡기 위한 값이지, 공격자가 의도적으로 바꾼 데이터를 검증하는 보안 장치가 아닙니다.
무결성이나 인증이 필요한 프로토콜에서는 CRC가 아니라 MAC, signature, AEAD 같은 보안 메커니즘을 별도로 사용해야 합니다.
한 줄 요약
Ethernet CRC and FCS Calculator는 Ethernet CRC-32 값을 계산하고, 실제 frame 끝에 붙는 FCS byte order와 captured trailer 검증까지 한 번에 확인하는 브라우저 기반 네트워크 도구입니다.