Category: DoIP
DoIP 카테고리에 작성된 글 목록입니다.
DoIP Roadmap
TCP는 붙었는데 진단은 왜 실패할까. DoIP를 연결, 라우팅, 세션, 타임아웃 관점으로 차근차근 읽는 순서입니다.
처음부터 순서대로 읽어도 좋고, 막히는 지점이 분명하다면 해당 묶음부터 바로 읽어도 좋습니다.
입문과 구조
- DoIP 개론, CAN 진단 보다가 처음 보면 헷갈리는 포인트 정리
CAN 진단에 익숙한 상태에서 DoIP를 처음 볼 때 잡아야 할 큰 그림을 정리합니다.
- DoIP 프로토콜 구조 뜯어보기, 헤더와 필드는 어떻게 생겼나
DoIP 패킷을 읽기 위한 header, payload type, payload length의 기본 구조를 봅니다.
- DoIP는 TCP stream이다: recv()만 믿고 파싱하면 깨지는 이유
TCP stream에서 DoIP 메시지를 안정적으로 framing/파싱하는 기본 패턴을 정리합니다.
Discovery와 연결 준비
- DoIP Vehicle Identification, 처음 연결할 때 이거부터 이해하자
DoIP에서 대상 차량이나 ECU를 찾고 다음 연결 단계로 넘어가기 위한 discovery 기본 흐름입니다.
- DoIP Vehicle Discovery가 가끔 안 잡히는 이유
Discovery가 간헐적으로 실패할 때 UDP broadcast, interface, boot timing을 어떻게 봐야 하는지 다룹니다.
- DoIP는 붙었는데 진단이 안 된다: Entity Status/Power Mode로 상태부터 확인하기
Vehicle discovery 이후에 '살아있는지/진단 가능한 상태인지'를 빠르게 가르는 체크 포인트(상태/전원 모드)를 정리합니다.
- DoIP Routing Activation, 여기서 막히는 이유 정리해보자
TCP 연결 이후 왜 Routing Activation이 필요하고, 여기서 왜 자주 막히는지 정리합니다.
Diagnostic Message와 라우팅
- DoIP Diagnostic Message, UDS가 실제로 어떻게 실리는지 보자
UDS 데이터가 DoIP Diagnostic Message 안에 어떻게 실리고 SA/TA가 왜 중요한지 봅니다.
- Routing Activation은 됐는데 첫 UDS가 실패한다: SA/TA와 재연결 순서를 같이 보자
Routing Activation 이후 첫 UDS 요청이 실패할 때 SA/TA와 재연결 순서를 어떻게 봐야 하는지 정리합니다.
- DoIP Gateway 구조를 이해해야 ECU가 보인다
TCP endpoint와 실제 ECU가 다른 gateway 환경에서 logical address와 internal routing을 읽는 방법입니다.
- DoIP에서 UDS를 ISO-TP처럼 자르면 안 된다: Diagnostic Message 경계를 먼저 봐야 한다
DoIP에서 UDS를 CAN-TP처럼 조각내어 다뤄 버리는 구현 실수와 Diagnostic Message 경계 기준을 정리합니다.
- DoIP Functional Address는 왜 응답이 이상하게 보일까
Functional request에서 여러 ECU 응답, source tracking, timeout policy가 왜 중요한지 정리합니다.
- DoIP에서 두 테스터가 같은 Source Address를 쓰면 응답이 꼬인다: SA 충돌을 timeout처럼 보면 오래 헤맨다
두 테스터나 두 프로세스가 같은 Source Address를 쓸 때 응답이 섞이거나 사라져 보이는 패턴을 정리합니다.
세션과 유지 관리
- DoIP에서 Session Control 먼저 이해해야 하는 이유
연결이 됐어도 ECU 기능이 열리지 않는 이유를 UDS Session Control 관점에서 봅니다.
- DoIP에서 한동안 가만히 두면 첫 요청만 timeout 난다: 살아 있는 것처럼 보이는 TCP socket을 먼저 의심하자
유휴 시간이 길어진 뒤 첫 요청만 실패하는 stale TCP socket 패턴과 재연결 판단 기준을 정리합니다.
- DoIP에서 Tester Present 왜 계속 보내는 걸까
Tester Present가 왜 주기적으로 나가고, 진단 세션 유지와 어떤 관계가 있는지 정리합니다.
- DoIP에서 Response Pending 중 Tester Present를 섞으면 꼬인다: 같은 세션 유지와 대기 흐름을 분리해서 봐야 한다
Response Pending 동안 Tester Present를 같은 흐름에 섞어 보내다 세션과 응답 매칭이 꼬이는 패턴을 정리합니다.
- DoIP 통신이 가끔 끊긴다: Alive Check / TCP Keepalive / Tester Present를 분리해서 보자
Alive Check, TCP Keepalive, Tester Present를 분리해서 세션 끊김을 분석하는 글입니다.
- DoIP에서 ECU Reset 후 다시 안 붙는다: 소켓 종료와 재연결 순서를 같이 봐야 한다
ECU Reset 이후 소켓 종료와 재연결 타이밍이 어긋나며 첫 진단이 실패하는 패턴을 정리합니다.
- DoIP Security Access, 여기서부터 ECU 성격이 확 달라진다
Seed/Key 기반 Security Access가 ECU 정책과 세션 상태에 따라 어떻게 달라지는지 봅니다.
- DoIP에서 Security Access 뒤 NRC 0x24가 뜬다: seed/key 이후 요청 순서와 세션 문맥을 같이 봐야 한다
Security Access 뒤 NRC 0x24가 날 때 seed/key 순서와 세션 문맥이 어떻게 어긋나는지 정리합니다.
응답과 타임아웃 디버깅
- DoIP timeout 처리, Response Pending 제대로 이해해야 덜 헤맨다
Response Pending 0x78과 timeout 정책을 잘못 보면 정상 ECU도 실패로 보이는 이유를 다룹니다.
- DoIP에서 NRC 0x21이 반복된다: Busy Repeat Request를 timeout처럼 다루면 꼬인다
NRC 0x21을 timeout처럼 처리해 재전송이 꼬이는 패턴과 retry 정책 분리 포인트를 정리합니다.
- DoIP에서 응답이 이상할 때, Negative Response부터 봐야 한다
UDS Negative Response와 NRC를 보고 통신 문제와 ECU 정책 문제를 구분하는 기본 글입니다.
- DoIP에서 NRC 0x13이 뜬다: 메시지 길이 오류를 TCP 조각 문제로 착각하지 말자
NRC 0x13이 반복될 때 DoIP payload length와 UDS 서비스 길이를 분리해서 확인하는 흐름을 정리합니다.
- DoIP에서 NRC 0x22가 뜬다: 조건 미충족을 통신 timeout처럼 보지 말자
NRC 0x22가 반복될 때 통신 문제보다 세션, 보안, 전원 상태, ECU precondition을 먼저 나눠 보는 흐름입니다.
- DoIP에서 NRC 0x31이 뜬다: DID와 Routine ID 범위를 세션 문제와 나눠 보자
NRC 0x31이 반복될 때 DID/Routine ID 범위 문제와 세션/보안 조건 문제를 나눠 보는 흐름입니다.
- DoIP에서 ACK를 받았는데 UDS 응답이 없다: Diagnostic ACK/NACK를 제대로 쓰는 법
DoIP ACK/NACK와 UDS 응답을 분리해서 ACK를 성공으로 오해하지 않도록 정리합니다.
- DoIP Negative Acknowledge, UDS 에러랑은 다르다
DoIP NACK와 UDS 0x7F를 구분해서 parser/protocol 문제와 application 문제를 나눠 봅니다.
Firmware Transfer
- DoIP Firmware Download에서 갑자기 문제가 터지는 이유
Firmware download에서 large payload, TCP stream parser, flash latency, retry state가 왜 터지는지 봅니다.
최근 글
-
DoIP에서 NRC 0x31이 뜬다: DID와 Routine ID 범위를 세션 문제와 나눠 보자
DoIP에서 UDS 요청 후 NRC 0x31 Request Out Of Range가 오면 통신 실패보다 요청한 DID, Routine ID, sub-function, 세션별 지원 범위를 먼저 확인해야 한다. 0x22, 0x13과 헷갈리지 않도록 서비스 범위와 ECU 상태 조건을 분리해 보는 디버깅 순서를 정리한다.
-
DoIP에서 NRC 0x22가 뜬다: 조건 미충족을 통신 timeout처럼 보지 말자
DoIP에서 UDS 요청 후 NRC 0x22 Conditions Not Correct가 오면 TCP timeout이나 Routing Activation 문제가 아니라 ECU가 현재 상태에서 그 서비스를 수행할 조건이 아니라고 보는 편이 빠르다. 세션, Security Access, 전원 모드, Tester Present, 이전 작업 상태를 함께 확인하는 디버깅 순서를 정리한다.
-
DoIP에서 NRC 0x13이 뜬다: 메시지 길이 오류를 TCP 조각 문제로 착각하지 말자
DoIP에서 UDS 요청은 ECU까지 도착하는데 NRC 0x13 Incorrect Message Length or Invalid Format이 반복되면 TCP 조각이나 Routing Activation보다 먼저 DoIP Diagnostic Message 길이와 UDS 서비스별 payload 길이를 나눠 봐야 한다. Generic Header length, SA/TA, UDS payload 경계를 분리해 확인하는 디버깅 순서를 정리한다.
-
-
DoIP에서 한동안 가만히 두면 첫 요청만 timeout 난다: 살아 있는 것처럼 보이는 TCP socket을 먼저 의심하자
DoIP에서 Routing Activation까지는 정상처럼 보였는데 몇 분 또는 몇십 분 유휴 후 첫 UDS 요청만 timeout처럼 사라지면, ECU보다 먼저 이미 끊긴 TCP socket을 앱이 계속 살아 있다고 믿는 상태를 확인해야 한다. keepalive, Alive Check, 재연결 조건을 분리해 두는 편이 안전하다.
-
DoIP에서 두 테스터가 같은 Source Address를 쓰면 응답이 꼬인다: SA 충돌을 timeout처럼 보면 오래 헤맨다
DoIP에서 Routing Activation까지는 되는 것 같은데 UDS 응답이 가끔 다른 요청에 붙거나 timeout처럼 사라져 보이면, ECU보다 먼저 Source Address를 누가 같이 쓰고 있는지 확인해야 한다. 같은 SA를 공유하면 응답 매칭과 세션 문맥이 쉽게 꼬인다.
-
DoIP에서 Response Pending 중 Tester Present를 섞으면 꼬인다: 같은 세션 유지와 대기 흐름을 분리해서 봐야 한다
DoIP에서 긴 UDS 작업 중 NRC 0x78 Response Pending이 오는 동안 Tester Present를 같은 소켓과 같은 요청 흐름에 무심코 섞어 보내면, 대기 중인 서비스 응답과 keepalive 목적의 세션 유지 요청이 충돌해 로그 해석과 재시도 정책이 쉽게 꼬인다. 두 흐름을 분리해 관리하는 편이 안전하다.
-
DoIP에서 UDS를 ISO-TP처럼 자르면 안 된다: Diagnostic Message 경계를 먼저 봐야 한다
DoIP에서 UDS 요청이 길어질 때 CAN의 ISO-TP처럼 프레임을 쪼개어 처리하려 들면 길이 계산, 재전송, 응답 매칭이 쉽게 꼬인다. DoIP는 TCP stream 위에서 Generic Header의 payload length로 메시지 경계를 잡고, UDS 한 요청을 Diagnostic Message 단위로 다루는 편이 안전하다.
-
DoIP에서 Security Access 뒤 NRC 0x24가 뜬다: seed/key 이후 요청 순서와 세션 문맥을 같이 봐야 한다
DoIP에서 Security Access 자체는 되는 것 같은데 unlock 직후 요청이 NRC 0x24 Request Sequence Error로 실패하면, key 계산보다 먼저 seed/key 순서와 세션 문맥이 유지됐는지 봐야 한다. 재연결, 세션 전환, 병렬 요청이 끼면 같은 ECU라도 이전 unlock 흐름이 쉽게 무효화된다.
-
DoIP에서 ECU Reset 후 다시 안 붙는다: 소켓 종료와 재연결 순서를 같이 봐야 한다
DoIP에서 UDS ECU Reset 이후 연결이 살아 있는 것처럼 보이는데 다음 진단이 실패하면, ECU 애플리케이션보다 먼저 소켓 종료, Routing Activation 재수행, Tester Present 재개 순서를 확인해야 한다. reset 전후를 같은 세션으로 취급하면 ACK는 보이는데 실제 UDS가 안 붙는 식으로 쉽게 꼬인다.
-
DoIP에서 NRC 0x21이 반복된다: Busy Repeat Request를 timeout처럼 다루면 꼬인다
DoIP에서 UDS 요청 후 NRC 0x21 Busy Repeat Request가 반복되면 ECU가 죽은 게 아니라 아직 같은 자원을 점유 중인 경우가 많다. timeout과 같은 정책으로 재전송하면 세션이 더 꼬일 수 있어서, 0x21 전용 retry 간격과 요청 직렬화 기준을 따로 두는 편이 안전하다.