Wireshark로 Ethernet packet을 열어봤는데 frame 끝에 FCS가 안 보일 때가 많다.
Ethernet frame에는 CRC/FCS가 붙는다고 배웠는데, 실제 캡처에는 destination MAC, source MAC, EtherType, payload만 보이고 마지막 4바이트 CRC가 없다.
처음 보면 이런 생각이 든다.
"내 캡처가 잘못된 건가?"
"Wireshark가 FCS를 숨기는 건가?"
"NIC가 CRC를 계산하지 않는 건가?"대부분의 경우 답은 더 단순하다.
NIC와 드라이버가 FCS를 하드웨어에서 처리하고, OS로 올릴 때는 제거해버린다.
Ethernet FCS는 어디에서 처리되나
Ethernet FCS는 frame trailer에 붙는 4바이트 checksum이다.
수신 쪽에서는 NIC가 이 값을 이용해 frame이 깨졌는지 확인한다.
Wire
Ethernet frame + FCS
|
v
NIC hardware
CRC/FCS check
|
v
Driver / OS capture path
usually frame without FCS
|
v
Wireshark즉 Wireshark가 보는 시점에는 이미 FCS가 제거된 뒤인 경우가 흔하다.
그래서 Wireshark에 FCS가 보이지 않는다고 해서 Ethernet CRC가 없다는 뜻은 아니다.
왜 기본 캡처에는 FCS가 없는가
가장 흔한 이유는 다음 세 가지다.
- NIC가 FCS를 수신 검사에만 사용하고 host memory로 넘기지 않는다.
- 드라이버가 FCS trailer를 제거한 frame만 OS capture stack에 전달한다.
- 캡처 장비나 OS 설정이 FCS capture를 지원하지 않는다.
대부분의 PC 환경에서는 일반적인 패킷 캡처만으로 FCS를 보기 어렵다.
특수한 NIC, 드라이버 옵션, 전용 capture 장비가 있어야 보이는 경우가 많다.
FCS가 없으면 CRC 검증을 못 하나
캡처에 FCS가 없으면 captured FCS와 expected FCS를 직접 비교할 수는 없다.
하지만 캡처된 frame byte를 기준으로 “이 frame에 붙어야 할 FCS가 무엇인지”는 계산할 수 있다.
예를 들어 아래 byte가 캡처되어 있고 FCS는 빠져 있다고 하자.
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들에 대해 Ethernet CRC를 계산하면 다음 값이 나온다.
CRC-32 value: 0x4A132CA5
FCS bytes on wire: A5 2C 13 4A즉 캡처 파일에 FCS가 없더라도, 같은 frame이 wire에 나갈 때 붙었을 FCS 값은 계산해볼 수 있다.
FCS가 포함된 캡처를 보면 어떻게 다를까
만약 캡처 데이터 끝에 FCS가 포함되어 있다면 마지막 4바이트를 별도로 봐야 한다.
예를 들어 표준 테스트 문자열 123456789를 ASCII byte로 쓰면 다음과 같다.
31 32 33 34 35 36 37 38 39여기에 Ethernet-style CRC/FCS를 붙이면 다음처럼 된다.
31 32 33 34 35 36 37 38 39 26 39 F4 CB여기서 마지막 26 39 F4 CB가 FCS다.
검증할 때는 마지막 4바이트를 계산 입력에서 제외하고, 앞의 byte들만으로 CRC를 다시 계산한 뒤 비교해야 한다.
Wireshark에서 볼 때 자주 하는 착각
1. “Frame length가 생각보다 4바이트 짧다”
FCS가 제거된 캡처라면 당연히 wire의 전체 frame보다 4바이트 짧게 보일 수 있다.
캡처 도구가 보여주는 length가 항상 물리 매체에서 본 octet 수와 완전히 같다고 보면 안 된다.
2. “CRC error frame이 안 보인다”
일반 NIC는 CRC error가 난 frame을 host로 올리지 않고 버리는 경우가 많다.
그래서 Wireshark에서 깨진 frame을 직접 보지 못할 수 있다.
CRC error counter는 Wireshark보다 NIC 통계, switch port counter, driver counter에서 확인하는 편이 나을 때가 많다.
3. “FCS가 없으니 CRC offload 문제다”
FCS가 캡처에 안 보이는 것과 IP/TCP/UDP checksum offload는 다른 층의 문제다.
Ethernet FCS는 L2 frame trailer이고, TCP checksum offload는 L4 checksum 처리다.
둘을 같이 의심하면 디버깅 방향이 쉽게 꼬인다.
FCS 관련 문제를 확인하는 순서
Ethernet CRC/FCS가 의심될 때는 이렇게 보는 것이 좋다.
- 캡처 환경이 FCS capture를 지원하는지 확인한다.
- 캡처된 frame 끝에 실제로 4바이트 trailer가 있는지 확인한다.
- FCS가 없다면 expected FCS만 계산해 참고값으로 쓴다.
- FCS가 있다면 마지막 4바이트를 captured FCS로 분리한다.
- 앞의 byte들만으로 CRC를 계산해 captured FCS와 비교한다.
- CRC error frame 자체가 필요한 경우 NIC/switch counter나 전용 장비를 본다.
여기서 가장 중요한 것은 “캡처에 FCS가 없는 상황”과 “FCS가 틀린 상황”을 구분하는 것이다.
빠른 계산 도구
FCS가 포함된 frame인지 아닌지만 구분할 수 있으면, 계산은 Ethernet CRC and FCS Calculator로 빠르게 확인할 수 있다.
- FCS가 없는 캡처: 그대로 붙여 넣고 expected FCS 확인
- FCS가 있는 캡처:
Input includes trailing FCS옵션을 켜고 비교
도구는 마지막 4바이트를 captured FCS로 분리해 expected FCS와 비교한다.
한 줄 요약
Wireshark에서 Ethernet FCS가 안 보이는 것은 대개 정상이다. 대부분의 NIC와 드라이버가 FCS를 하드웨어에서 검사한 뒤 제거하므로, FCS가 필요한 디버깅은 캡처 환경 지원 여부와 expected FCS 계산을 나눠서 봐야 한다.