DoIP Negative Acknowledge, UDS 에러랑은 다르다

DoIP 디버깅하다 보면 자주 헷갈리는 게 있습니다.

Negative Response

로그에 이렇게 찍혀 있으면 보통 UDS 0x7F부터 떠올립니다.
그런데 실제로는 DoIP 자체에서 발생하는 Negative Acknowledge도 존재합니다.

이 둘은 완전히 다른 레이어입니다.

• UDS Negative Response
• DoIP Negative Acknowledge

이걸 섞어서 보면 디버깅 방향이 틀어집니다.

시리즈 목차

• DoIP Routing Activation, 여기서 많이 막힌다
• DoIP Diagnostic Message, 결국 중요한 건 이 패킷이다
• DoIP Alive Check, 연결은 살아 있는데 왜 끊겼을까
• DoIP Negative Acknowledge, UDS 에러랑은 다르다

먼저 구분부터 하자

두 개를 아주 단순하게 나누면:

DoIP NACK
= transport / protocol level 문제

UDS 0x7F
= diagnostic application level 문제

입니다.

예를 들어:

• DoIP header 형식이 틀림
• payload length 이상함
• message type 지원 안 함

이런 건 DoIP 레벨 문제입니다.

반면:

• Security Access 거부
• Session 조건 불만족
• DID 지원 안 함

이런 건 UDS 레벨 문제입니다.

패킷 흐름으로 보면

DoIP NACK

Tester
  |
  |--- Invalid DoIP Message --------> ECU
  |
  |<-- DoIP Negative Acknowledge ----|

이 경우 ECU는 UDS까지 가지 못합니다.

즉:

DoIP parser 단계에서 실패

입니다.

UDS Negative Response

반면 이 경우는 다릅니다.

Tester
  |
  |--- Valid DoIP + UDS Request ----> ECU
  |
  |<-- UDS Negative Response (0x7F)-|

여기서는:

• DoIP transport는 정상
• UDS application 처리 중 실패

입니다.

즉, 이미 ECU 내부 UDS 로직까지 들어간 상태입니다.

현장에서 많이 헷갈리는 로그

예를 들면 이런 상황입니다.

RX: 7F 22 31

이건 UDS negative response입니다.

반면 아래는 DoIP 자체 문제일 가능성이 큽니다.

invalid payload length
unsupported payload type
generic header nack

문제는 일부 로그 시스템이 둘 다 그냥:

negative response

로 뭉개서 출력한다는 점입니다.

이러면 분석이 어려워집니다.

로그 레벨을 분리하는 게 좋다

추천 방식은 최소한 prefix를 다르게 두는 겁니다.

예시:

[doip] nack code=0x..
[uds] negative response sid=0x22 nrc=0x31

이 정도만 해도 로그 읽기가 훨씬 편해집니다.

특히 firmware download처럼 패킷이 길어지면 transport 문제와 application 문제를 빨리 분리해야 합니다.

DoIP NACK가 자주 발생하는 상황

실제로는 이런 케이스가 많습니다.

1) payload length 계산 오류

예시:

header payload length = 20
actual payload size   = 18

상대 parser는 바로 reject합니다.

이 경우는 UDS까지 도달하지 않습니다.

2) unsupported payload type

구현체마다 지원 범위가 다릅니다.

예를 들어 일부 장비는 특정 payload type을 무시하거나 reject합니다.

특히 테스트 장비와 양산 ECU 조합에서 차이가 나기도 합니다.

3) protocol version mismatch

DoIP header에는 protocol version 정보가 있습니다.

여기 처리 실수로 reject되는 경우도 있습니다.

특히 직접 packet builder 작성할 때 종종 나옵니다.

4) malformed header

예를 들면:

• inverse version 값 불일치
• payload length 이상
• truncated packet
• TCP stream 조립 실패

이런 경우입니다.

결국 parser robustness 문제로 이어집니다.

TCP fragmentation이 원인인 경우도 있다

이 부분이 꽤 중요합니다.

예를 들어 recv 처리 잘못해서:

header 일부만 읽음

상태인데 parser를 돌리면 header 자체가 깨집니다.

그러면 ECU 입장에서는 malformed packet처럼 보입니다.

그래서 DoIP parser는 항상:

read exact header size
→ parse payload length
→ read exact payload size

순서를 지켜야 합니다.

UDS Negative Response는 오히려 정상 흐름일 수도 있다

이 부분도 중요합니다.

예를 들어:

7F 27 35

같은 응답은 transport 문제라기보다:

보안 인증 실패

에 가깝습니다.

즉:

• ECU가 요청을 이해했고
• UDS까지 처리했고
• 정책상 거부한 것

입니다.

그래서 UDS negative response는 오히려 통신 자체는 정상이라는 의미가 되기도 합니다.

실무에서는 레이어별로 분리해서 보자

추천 방식:

L4/TCP
  socket state

DoIP Layer
  routing activation
  alive state
  packet validation

UDS Layer
  session state
  security state
  diagnostic result

이렇게 분리하면 디버깅 속도가 훨씬 빨라집니다.

반대로 전부 “진단 실패” 하나로 묶으면 원인 추적이 길어집니다.

오늘 포인트

DoIP Negative Acknowledge와 UDS Negative Response는 완전히 다른 레이어입니다.

• DoIP NACK
  → transport/protocol 문제

• UDS 0x7F
  → application/diagnostic 문제

이 구분만 명확해져도 로그 읽는 속도가 꽤 빨라집니다.

다음 글에서는 DoIP에서 firmware download 시 왜 timeout과 segmentation 문제가 커지는지 이어서 다뤄보겠습니다.

추천 대상

• DoIP packet parser를 구현 중인 개발자
• UDS negative response와 transport error를 헷갈리는 엔지니어
• ECU diagnostic logging 구조를 개선하려는 사람

한 줄 요약

DoIP NACK는 transport/protocol 레이어 문제이고, UDS 0x7F는 diagnostic application 레이어 문제다.

추천 키워드

doip, negative acknowledge, uds negative response, automotive ethernet, diagnostic protocol, parser

DevBJ | No Bio, Just Log #오늘을살자