네트워킹이 작동하지 않을 때

Source: Hacker News

Source: …

여정

1. 첫 시도 – Windows XP VM + TSO

• Windows XP VM(NAT 네트워킹)에서 Tyan의 오래된 TSO (Tyan System Operator) 소프트웨어를 실행했습니다.
• 소프트웨어는 정상적으로 설치되었지만 IPMI가 활성화된 서버를 찾을 수 없었습니다.
• IPMI 주소를 수동으로 설정해도 실패했습니다.

2. 네이티브 Windows 도구

• ipmiutil(https://ipmiutil.sourceforge.net/)을 시도했습니다.
• 동일한 결과 – SMDC가 응답하지 않았습니다.

3. Windows 10 테스트 박스

• Windows 10이 설치된 오래된 PC에서 동일한 테스트를 반복했습니다.
• ipmiutil은 여전히 SMDC와 통신을 거부했습니다.

4. Linux로 전환

• 같은 하드웨어를 Linux로 부팅하고 ipmitool을 실행했습니다.

• 성공! ipmitool이 SMDC와 통신할 수 있었습니다.

• Linux 호스트에 Windows XP VM을 다시 설정했더니 TSO 소프트웨어가 정상적으로 동작했습니다.

5. 방화벽?

• 모든 Windows 호스트에서 Windows 방화벽을 비활성화했지만 변화가 없었습니다.

6. Windows 11에서 Wireshark 스니핑

• UDP 포트 623으로 나가는 트래픽과 SMDC로부터의 수신 응답을 확인했습니다.
• 응답 패킷은 캡처되었지만 어떤 애플리케이션도 이를 보지 못했습니다.

7. PktMon 조사

• PktMon을 실행해 Windows 네트워킹 스택을 통과하는 트래픽을 확인했습니다.
• 관심 있는 로그 항목:

DropReason INET: checksum is invalid

• 패킷은 NIC에 도달하고 몇몇 필터 레이어를 통과했지만 TCP/IP 스택이 UDP 체크섬이 잘못됐다고 판단해 버렸습니다.
• 그러나 Wireshark는 IP와 UDP 체크섬이 유효하다고 보고했습니다.

8. 드라이버 조정

• NIC: Intel I211(드라이버 e1r68x64.sys).
• IPv4용 UDP 수신 체크섬 오프로드를 비활성화했습니다.

결과: ipmiutil이 정상 작동했으며, 호스트의 VM도 SMDC와 통신할 수 있게 되었습니다.

• 동일한 수정(IPv4 UDP Rx 체크섬 오프로드 비활성화)이 Intel 82579LM(e1i65x64.sys)을 탑재한 Windows 10 머신에서도 문제를 해결했습니다.
• 오프로드 옵션이 없는 Killer Wireless 1525 어댑터를 장착한 Windows 10 노트북은 처음부터 영향을 받지 않았습니다.

여기서 무슨 일이 일어나고 있나요?

• UDP Rx 체크섬 오프로드는 일반적으로 신뢰할 수 있습니다; 그렇지 않으면 DHCP, DNS 등이 깨질 것입니다.
• SMDC의 UDP 패킷은 완전히 정상적으로 보입니다 (≈ 76 바이트, VLAN 태그 없음, 터널링 없음).
• Linux (같은 Intel NIC에서도) 이 패킷을 받아들입니다.
• Windows TCP/IP 스택이 직접 체크섬을 검증해야 할 때도, 이 패킷이 정상이라고 판단합니다.

Rx 체크섬 오프로드 작동 방식

1. 하드웨어가 들어오는 패킷의 체크섬을 검증하고 수신 디스크립터에 유효/무효 플래그를 설정합니다.
2. 드라이버가 그 플래그를 상위 소프트웨어에 보고합니다.
3. TCP/IP 스택은 그 플래그를 신뢰하고 체크섬을 다시 계산하지 않습니다.

따라서, 가장 설득력 있는 설명은 Intel NIC 혹은 그 드라이버가 UDP 체크섬을 잘못 무효로 보고 있어, 스택이 정상적인 패킷을 버리고 있다는 것입니다.

나만 그런가?

• 이 문제를 진단하는 데 많은 시간이 걸렸다.
• 초기 의심은 SMDC(구형 IPMI 구현이 불안정할 수 있음)였지만, Wireshark는 원격 측이 올바른 응답을 보내고 있음을 증명했다.
• PktMon이 핵심이었다: “checksum is invalid” 드롭 사유를 드러내어 드라이버‑오프로드 조정을 유도했다.

온라인에서 찾은 내용

• 체크섬 오프로드가 신비한 문제를 일으킨다는 모호한 언급만 있었다.
• 일부 권고는 오프로드를 완전히 비활성화할 것을 제안하며, 디버깅 비용이 성능 향상보다 크다고 주장한다.

TL;DR

• Problem: Windows 10/11 시스템에서 Intel NIC를 사용하는 경우, NIC 드라이버가 잘못된 UDP Rx 체크섬 상태를 보고하여 유효한 IPMI UDP 응답을 버렸습니다.
• Fix: NIC 드라이버에서 IPv4 UDP 수신 체크섬 오프로드를 비활성화합니다 (예: 장치 관리자 → 고급 → UDP Checksum Offload → 사용 안 함).
• Result: IPMI 도구(ipmiutil, TSO, 가상 머신) 가 Tyan SMDC와 정상적으로 동작합니다.

Windows에서 레거시 IPMI 장치가 “응답 없음” 문제를 겪는 경우, 먼저 NIC의 체크섬 오프로드 설정을 전환해 보세요.

Possible Cause

인텔 Windows 드라이버를 역어셈블하고 추적하지 않고는(제가 하고 싶지 않은 일이라) 원인을 추측할 수밖에 없습니다. 저는 원인이 “Packet ID” 필드와 관련이 있을 것이라고 생각합니다. 실제로 2013 RFC 6864에서는 ID 필드가 어떻게 사용되고 해석되어야 하는지를 재정의하고 있는데, 이는 이전 RFC들과 호환되지 않는 방식으로 사용되고 있다는 사실을 누군가가 깨달은 뒤에 작성된 것으로 보입니다(요컨대, ID가 너무 빨리 재사용되고 있었습니다).

Tyan SMDC의 TCP/IP 스택은 매우 단순하며 들어오는 패킷을 나가는 패킷의 템플릿으로 사용하는 것 같습니다. 그 결과 SMDC 입장에서는 들어오는 패킷과 나가는 패킷이 같은 ID를 갖게 됩니다. 그러나 나가는 패킷은 Do Not Fragment 로 표시되지 않으며, 이는 잠재적으로 문제를 일으킬 수 있습니다. 실제로는 조각화되지 않을 것이 거의 보장되지만, 인텔 Windows 드라이버의 UDP 체크섬 오프로드는 조각화에 민감하기 때문에 혼란을 야기할 수 있습니다.

Windows 드라이버를 어쩔 수 없이 수정할 수 없으므로 IPv4 UDP Rx 체크섬 오프로드를 끄는 것이 저에게는 완전히 실용적인 해결책입니다. 다만 원래는 그렇게 할 필요가 없을 텐데…