DoIP에서 ACK를 받았는데 UDS 응답이 없다: Diagnostic ACK/NACK를 제대로 쓰는 법

실무에서 이런 로그를 한 번쯤 본다.

Diagnostic Message 전송 OK
DoIP 쪽 ACK도 왔다
그런데 UDS 응답이 없다 (timeout)

이때 흔히 하는 착각이 이거다.

ACK가 왔으니 ECU가 처리한 거 아닌가?

결론부터 말하면,
DoIP ACK/NACK는 UDS 응답이 아니다.

오늘은 “ACK를 받았는데 왜 UDS가 없지?”를 빠르게 분해하기 위해
DoIP Diagnostic ACK/NACK를 어떻게 봐야 하는지 정리해본다.

한 줄로 구분하기

계층을 분리해서 보면 헷갈릴 일이 줄어든다.

TCP 연결: 소켓이 살아있냐
DoIP ACK/NACK: DoIP Entity(게이트웨이 포함)가 “이 Diagnostic Message를 처리/거부”했냐
UDS 응답: ECU가 서비스(예: 0x22, 0x10)를 처리하고 응답했냐 (Positive/Negative/NRC)

즉,

ACK는 “UDS 성공”이 아니고
NACK는 “UDS Negative Response”가 아니다

전형적인 흐름(그림으로)

보통은 이런 느낌이다.

Tester  --(TCP)-->  DoIP Entity/Gateway  --> ECU

1) Tester: Diagnostic Message(UDS Request) 전송
2) DoIP: (있다면) ACK 또는 NACK 수신
3) UDS: (있다면) ECU의 UDS Response 수신

여기서 포인트는 2)와 3)이 다른 신호라는 것.

ACK가 와도,
UDS 응답은 늦게 오거나 아예 안 올 수 있다.

“ACK가 왔는데 UDS가 없다”에서 갈리는 2가지 경우

1) DoIP는 받았지만 UDS까지는 못 갔다

ACK가 “게이트웨이가 TCP로 데이터를 받았다/처리 큐에 올렸다” 수준일 수 있다.

이 경우는 이후에:

게이트웨이 내부 라우팅 실패
내부 버스(CAN/LIN/Ethernet) 포워딩 실패
ECU 상태/세션 상태 때문에 무응답

같은 이유로 UDS 응답이 안 올 수 있다.

즉, ACK는 ‘최종 ECU 응답 보장’이 아니다.

2) UDS는 갔는데, 응답을 너(테스터)가 못 받는 구조다

예를 들면 이런 케이스다.

응답이 다른 소켓/다른 세션으로 가고 있다(멀티 테스터/재연결 꼬임)
응답을 받기 전에 세션이 끊겼다(네트워크 idle/Alive Check/Keepalive 이슈)
테스터 구현에서 수신 스레드/큐가 막혀 있다(버퍼 포화)

그래서 “ACK는 왔는데 응답이 없다”면
네트워크/DoIP/UDS를 동시에 의심하지 말고 분기부터 하자.

NACK가 왔을 때는 오히려 쉬워진다

NACK는 보통 이런 메시지다.

“이 Diagnostic Message는 DoIP 레벨에서 거절한다”

실무에서 자주 보는 NACK 원인은 대략 이 범주로 정리된다.

Source Address가 이상함: “너 누구냐” / 등록되지 않은 테스터 주소
Target Address를 모름: 해당 TA로 라우팅할 ECU가 없음
Routing Activation 상태가 아님: 아직 진단 경로가 열려있지 않음
메시지가 너무 큼/형식이 이상함: 길이/헤더/페이로드가 규격과 다름
리소스 부족/바쁨: 내부 큐/세션 리소스가 포화

표준 명칭/코드값은 구현마다 로그 표현이 조금 다를 수 있는데,
핵심은 동일하다.

UDS 레벨로 내려가기 전에, DoIP에서 이미 거절됐다

그래서 NACK가 보이면
UDS 디버깅보다 먼저 SA/TA/RA 상태부터 잡는 게 정답이다.

ACK/NACK를 디버깅에 써먹는 로그 포인트

개인적으로는 이 6개를 같이 남기면 추적이 빨라진다.

송신 시각 / 수신 시각(ACK/NACK, UDS Response 각각)
SA / TA
UDS Service ID(+subfunction/ID)
TCP 재연결 여부(소켓 ID/연결 카운터)
Routing Activation 성공 시각(또는 RA 재시도 횟수)
“현재 세션 상태”(진단 세션/시큐리티 레벨)

ACK/NACK만 따로 보면 힌트가 약하다.
UDS 요청/응답 로그와 같은 축으로 묶어서 봐야 한다.

빠른 체크리스트(현장용)

NACK가 보이면

SA가 Routing Activation 때 쓴 테스터 주소와 같은지 확인
TA가 실제 ECU/게이트웨이 라우팅 테이블에 존재하는지 확인
재연결 후 RA를 다시 했는지 확인(“TCP만 재연결” 실수 주의)
패킷 길이/헤더/페이로드가 깨지지 않았는지 Wireshark로 확인

ACK는 오는데 UDS 응답이 없으면

같은 소켓에서 응답이 돌아오는지(멀티 테스터/세션 꼬임) 확인
UDS 세션이 살아있는지(Tester Present, session timeout) 확인
ECU가 “무응답 정책”인 서비스인지 확인(예: suppress response)
Response Pending(0x78) 처리/타임아웃 정책이 맞는지 확인
게이트웨이 내부 포워딩/버스 부하로 지연이 늘었는지 확인

한 줄 요약

DoIP Diagnostic ACK/NACK는 DoIP 레벨 신호이고 UDS 응답과 별개라서, ACK를 “성공”으로 착각하지 말고 SA/TA/RA/세션 로그와 함께 디버깅 힌트로 써야 한다.