패킷은 정상인데 진단은 실패한다: DoIP 실무 디버깅 노트

차량 진단을 하다 보면 어느 순간 DoIP라는 단어를 만나게 됩니다.

처음에는 단순히 “UDS를 Ethernet으로 보내는 것” 정도로 보이는데, 실제로 구현하거나 디버깅하다 보면 생각보다 많은 지점에서 막힙니다.

TCP는 붙었는데 ECU 응답이 없고, Routing Activation은 성공했는데 UDS가 안 오고, 작은 요청은 잘 되는데 firmware download만 들어가면 timeout이 터지는 식입니다.

그래서 DoIP 관련해서 실무에서 헷갈렸던 포인트들을 하나씩 정리해두고 있습니다.

기본 흐름 이해하기

• DoIP 개론, CAN 진단 보다가 처음 보면 헷갈리는 포인트 정리
  CAN 기반 진단에 익숙한 상태에서 DoIP를 처음 볼 때 헷갈리는 큰 그림을 정리한 글입니다.

• DoIP 프로토콜 구조 뜯어보기, 헤더와 필드는 어떻게 생겼나
  DoIP 패킷을 실제로 읽기 시작할 때 필요한 header, payload type, payload length 같은 기본 구조를 다룹니다.

• DoIP Vehicle Identification, 처음 연결할 때 이거부터 이해하자
  차량이나 ECU를 네트워크에서 어떻게 찾는지, discovery 단계가 왜 필요한지 정리한 글입니다.

연결과 라우팅에서 막히는 부분

• DoIP Routing Activation, 여기서 막히는 이유 정리해보자
  TCP 연결은 됐는데 진단이 안 되는 상황에서 가장 먼저 봐야 하는 Routing Activation을 다룹니다.

• DoIP Diagnostic Message, UDS가 실제로 어떻게 실리는지 보자
  DoIP 안에 UDS 데이터가 어떻게 들어가는지, Source Address와 Target Address가 왜 중요한지 정리했습니다.

• DoIP Gateway 구조를 이해해야 ECU가 보인다
  실제 차량에서는 Tester와 ECU가 직접 붙는 게 아니라 Gateway를 거치는 경우가 많습니다. logical address와 gateway routing 관점에서 로그를 보는 방법을 정리했습니다.

UDS와 세션 관리

• DoIP에서 Session Control 먼저 이해해야 하는 이유
  연결이 됐다고 모든 진단 기능이 바로 되는 것은 아닙니다. ECU session 상태가 왜 중요한지 다룹니다.

• DoIP Security Access, 여기서부터 ECU 성격이 확 달라진다
  Seed/Key 기반 Security Access 흐름과 ECU마다 달라지는 인증 정책을 가볍게 정리한 글입니다.

• DoIP에서 Tester Present 왜 계속 보내는 걸까
  진단 세션을 유지하기 위해 Tester Present가 왜 필요한지, Alive Check와는 어떻게 다른지 다룹니다.

Timeout과 응답 해석

• DoIP timeout 처리, Response Pending 제대로 이해해야 덜 헤맨다
  Response Pending 0x78을 제대로 처리하지 않으면 정상 ECU도 timeout으로 오해할 수 있습니다.

• DoIP에서 응답이 이상할 때, Negative Response부터 봐야 한다
  UDS Negative Response 구조와 NRC를 어떻게 해석하면 좋은지 정리했습니다.

• DoIP에서 ACK를 받았는데 UDS 응답이 없다: Diagnostic ACK/NACK를 제대로 쓰는 법
  DoIP ACK/NACK와 UDS 응답을 혼동하지 않도록 레이어를 분리해서 보는 글입니다.

• DoIP Negative Acknowledge, UDS 에러랑은 다르다
  DoIP NACK와 UDS 0x7F는 전혀 다른 레이어의 문제입니다. 로그에서 이 둘을 구분하는 관점을 정리했습니다.

실무에서 자주 터지는 문제들

• DoIP 통신이 가끔 끊긴다: Alive Check / TCP Keepalive / Tester Present를 분리해서 보자
  TCP 연결은 살아 있는데 DoIP 세션이나 UDS 세션은 죽어 있을 수 있습니다. Alive Check, TCP Keepalive, Tester Present를 분리해서 보는 글입니다.

• DoIP Functional Address는 왜 응답이 이상하게 보일까
  Functional request는 하나의 ECU만 대상으로 하는 요청이 아니기 때문에 응답 수집과 source tracking이 중요합니다.

• DoIP Firmware Download에서 갑자기 문제가 터지는 이유
  작은 진단 요청은 잘 되는데 firmware flashing에서 timeout, parser 오류, throughput 문제가 터지는 이유를 정리했습니다.

• DoIP Vehicle Discovery가 가끔 안 잡히는 이유
  Discovery는 UDP 기반이라 boot timing, interface 선택, broadcast forwarding, discovery cache 영향을 많이 받습니다.

정리

DoIP는 단순히 UDS를 TCP/IP 위에 올린 것처럼 보이지만, 실제로는 훨씬 더 많은 상태를 같이 봐야 합니다.

• TCP 연결 상태
• Routing Activation 상태
• DoIP session 상태
• UDS session 상태
• Gateway routing 상태
• Timeout / retry 정책
• Discovery timing

이런 것들이 서로 엮여 있어서, 한 레이어만 보고 판단하면 디버깅이 길어지는 경우가 많습니다.

그래서 이 글들은 단순한 프로토콜 설명보다는 실제 구현과 디버깅에서 자주 헷갈리는 지점을 중심으로 정리하고 있습니다.

DoIP를 처음 붙여보는 사람이나, “패킷은 정상 같은데 왜 안 되지?” 상황을 겪는 사람에게 도움이 되었으면 합니다.