tags: DoIP, Wireshark, PCAP, Packet Analysis, 디버깅, Hex Dump, DevBJ
안녕하세요, DevBJ입니다! 😎
[👉 1편]에서 파이썬으로 튼튼한 DoIP 파서를 만들었지만, 실무를 하다 보면 내 코드가 잘못된 건지, 아니면 저쪽 ECU(차량)가 이상한 패킷을 뱉는 건지 도무지 알 수 없는 '깜깜이' 상황에 처할 때가 많습니다.
📌 [DoIP 마스터 가이드 시즌 2: 실전 심화편 목차]
[IT/자동차] - [DoIP 마스터 가이드 시즌2 - 1편] 파이썬(Python)으로 직접 짜보는 DoIP 파서와 TCP 프레이밍 구현
[IT/자동차] - [DoIP 마스터 가이드 시즌2 - 2편] Wireshark 실전! 패킷 덤프(PCAP)로 뜯어보는 DoIP 흐름과 디버깅
[IT/자동차] - [DoIP 마스터 가이드 시즌2 - 3편] UDS 딥다이브! 악명 높은 보안 접속(0x27)과 루틴 제어(0x31) 해부
[IT/자동차] - [DoIP 마스터 가이드 시즌2 - 4편] 실전 엣지 케이스! "왜 이 상황에서만 통신이 죽을까? (完)
이럴 때 개발자들의 영원한 구원자이자 진실의 방(Room of Truth)이 있으니... 바로 Wireshark(와이어샤크) 입니다.
오늘은 DoIP 통신이 막혔을 때 패킷 덤프(PCAP)를 열어보고, 헥사(Hex) 데이터가 의미하는 바를 매의 눈으로 찾아내는 실전 디버깅 노하우를 공유하겠습니다.
1. 헥사(Hex) 덤프와 친해지기: 8바이트 헤더의 해부
Wireshark를 켜고 필터에 tcp.port == 13400을 걸면 DoIP 패킷들이 주르륵 나옵니다.
데이터(Payload) 영역을 클릭하면 아래 창에 알 수 없는 헥사 값들이 보일 텐데요, 이 값들을 눈으로 빠르게 읽어내는 훈련이 필요합니다.
🔍 [상황 1] Routing Activation Request (테스터 -> 차량)
Wireshark 데이터 창에 아래와 같이 찍혔다고 가정해 봅시다.
02 FD 00 05 00 00 00 07 0E 80 00 00 00 00 00
이걸 1편에서 배운 구조대로 잘라보면 1초 만에 해석이 됩니다.
02 FD: DoIP 버전 (0x02) / 반전 값 (0xFD) -> 정상!00 05: Payload Type (0x0005) -> Routing Activation Request!00 00 00 07: Payload Length -> 7 bytes0E 80: 테스터의 Source Address (SA) -> 0x0E8000: Activation Type -> 0x00 (Default)00 00 00 00: 예약(Reserved) 영역 4 bytes
[디버깅 포인트]: 만약 연결이 안 된다면, 내가 보낸 SA(0E 80)가 OEM 규격서에 정의된 테스터 주소가 맞는지, Activation Type(00)이 맞게 들어갔는지 패킷을 보고 확인해야 합니다. 내 코드엔 맞게 적었어도 Endian(바이트 순서) 문제로 80 0E로 거꾸로 날아가고 있을 수도 있습니다!
2. 실전 트러블슈팅: Wireshark로 범인 찾기
개발 중 겪게 되는 대표적인 에러 상황 2가지를 Wireshark 관점에서 뜯어보겠습니다.
🚨 케이스 1: "연결은 됐는데 UDS 응답이 전혀 안 와요!" (침묵의 ECU)
코드를 돌려보니 Routing Activation까지는 성공(0x0006)을 받았는데, UDS 요청(0x22 등)을 쏘면 Timeout이 나버립니다. Wireshark를 열어봅니다.
내가 보낸 패킷 (Diagnostic Message):02 FD 80 01 00 00 00 07 0E 80 10 01 22 F1 90
80 01: Payload Type -> Diagnostic Message 맞음.0E 80: 내 주소(SA) 맞음.10 01: Target Address (TA) -> 0x100122 F1 90: UDS Payload -> ReadData(0x22) DID(F190)
범인 찾기: 차량 쪽에서 아무런 TCP ACK나 DoIP 응답이 없다면, 99% Target Address(TA) 오류입니다. 내 UDS 메시지를 받은 게이트웨이가 "어? 0x1001이라는 주소는 우리 차에 없는데?" 하고 패킷을 그냥 Drop(버림) 시켜버린 겁니다. OEM 문서를 열어 진짜 엔진 ECU의 주소가 0x1001이 맞는지 0x1011은 아닌지 확인하세요.
🚨 케이스 2: "무언가 응답이 오긴 했는데 코드가 뻗어요!" (NACK의 습격)
UDS 요청을 보냈더니 ECU가 쏜살같이 대답했는데, 내 파서가 그걸 파싱하다가 Exception을 뿜으며 죽어버립니다. Wireshark를 봅니다.
ECU가 보낸 패킷:02 FD 00 00 00 00 00 01 04
00 00: Payload Type -> Generic DoIP Header NACK!00 00 00 01: Payload Length -> 1 byte04: NACK Code -> 0x04 (Invalid Payload Length)
범인 찾기: 에러의 원인은 차량이 아니라 내 코드에 있었습니다! 내가 보낸 패킷의 Payload Length 값을 잘못 계산해서 헤더에 우겨넣어 보냈더니, 게이트웨이가 검사해 보고 "너 길이 계산 틀렸어(0x04)" 라고 뺨을 때린 상황입니다. (UDS NRC인 7F가 아니라, DoIP 단의 NACK입니다!)
3. Wireshark 분석 시 꿀팁
- TCP 재조립(Reassembly) 켜기: Wireshark 설정(Preferences -> Protocols -> TCP)에서
Allow subdissector to reassemble TCP streams옵션이 켜져 있는지 확인하세요. 이게 켜져 있어야 패킷이 파편화되어 와도 Wireshark가 예쁘게 하나의 패킷으로 묶어서 보여줍니다. - 커스텀 Lua 디섹터(Dissector) 활용: 헥사 값을 매번 눈으로 쪼개기 눈알이 빠질 것 같다면, GitHub 등에서
DoIP Wireshark Lua Dissector를 검색해서 설치해 보세요. 마치 HTTP 패킷 보듯이 DoIP 헤더와 SA/TA를 트리 구조로 깔끔하게 파싱해서 보여줍니다. (삶의 질이 수직 상승합니다 🚀)
📝 2편 마무리
Wireshark는 네트워크를 타는 개발자에게는 거짓말을 하지 않는 유일한 친구입니다. 내 코드의 로그만 믿지 말고, "진짜로 랜선(물리 계층)을 타고 나간 바이트 배열"이 무엇인지 확인하는 습관을 들이시면 트러블슈팅 속도가 비약적으로 빨라질 것입니다.
자, 이제 패킷을 까보는 법도 알았으니 진단 통신의 양대 산맥이자 악명이 자자한 UDS 서비스 깊은 곳으로 들어가 보겠습니다.
👉 [다음 글 보기: 시즌2 - 3편. 악명 높은 보안 접속(0x27)과 루틴 제어(0x31) 완벽 해부]
디버깅 중에 헥사 값이 이해 안 가시면 댓글로 덤프를 살짝 남겨주세요! DevBJ였습니다.