DoIP Vehicle Discovery가 가끔 안 잡히는 이유

DoIP 처음 붙일 때 가장 먼저 하는 건 보통 Discovery입니다.

툴 실행하면 ECU가 보여야 하고,
IP 주소도 잡혀야 하고,
Vehicle Identification 응답도 와야 합니다.

그런데 실제로는 가끔 이런 상황이 나옵니다.

ECU가 안 보임
한 번은 되고 한 번은 안 됨
부팅 직후 discovery 실패
gateway 재시작 후 응답 없음

이런 문제는 생각보다 흔합니다.

그리고 대부분은 UDS 문제가 아니라 Discovery timing 문제입니다.

시리즈 목차

Discovery는 UDP 기반이다

여기서 많이 놓칩니다.

실제 diagnostic traffic은 TCP 기반이지만,
Discovery는 보통 UDP broadcast/multicast 기반입니다.

흐름은 대략 이렇습니다.

Tester
  |
  | Vehicle Identification Request
  | UDP Broadcast
  v
Network

ECU / Gateway
  |
  | Vehicle Identification Response
  v
Tester

즉:

Discovery = UDP
Diagnostic Session = TCP

입니다.

그래서 timing 영향을 많이 받는다

TCP는 연결 기반이라 상태가 비교적 안정적입니다.

반면 UDP discovery는:

boot timing
interface ready 상태
switch forwarding 상태
multicast/broadcast 정책

영향을 많이 받습니다.

특히 gateway boot 직후가 문제입니다.

부팅은 끝났는데 discovery는 아직 안 되는 경우

실제로 이런 상황이 있습니다.

Linux boot 완료
BUT
DoIP service 아직 초기화 중

또는:

Ethernet PHY up
BUT
routing table 아직 준비 안 됨

Tester 입장에서는 그냥:

ECU 안 보임

처럼 느껴집니다.

현장에서 자주 보는 패턴

1) 첫 discovery만 실패

예시:

Tester start
→ immediate discovery
→ no response
→ retry
→ 정상 발견

이 경우가 꽤 많습니다.

초기 network stabilization timing 때문입니다.

그래서 실제 툴들은 retry를 기본으로 넣는 경우가 많습니다.

2) Wi-Fi bridge 환경에서 이상함

테스트 환경에서 자주 나옵니다.

예를 들어:

PC
→ Wi-Fi AP
→ Ethernet adapter
→ ECU

구조입니다.

여기서 UDP broadcast forwarding이 제대로 안 되는 경우가 있습니다.

TCP 직접 연결은 되는데 discovery만 실패하기도 합니다.

3) Switch 정책 영향

일부 스위치 환경에서는:

multicast filtering
storm control
VLAN 설정

영향으로 discovery packet이 drop되기도 합니다.

특히 사내 테스트망에서 자주 헷갈립니다.

packet capture를 꼭 같이 봐야 한다

Discovery 문제는 Wireshark가 꽤 중요합니다.

최소한 아래는 확인하는 게 좋습니다.

1. request가 실제로 나가는가
2. response가 네트워크에 존재하는가
3. tester까지 도달하는가

생각보다:

request 송신 실패

인 경우도 많습니다.

특히 binding interface 잘못 잡으면 그렇습니다.

multi-interface PC도 자주 문제 된다

예를 들어 PC에:

Ethernet
Wi-Fi
VPN adapter
Docker bridge

가 같이 있으면 문제가 생기기 쉽습니다.

UDP broadcast가 예상 인터페이스가 아니라 다른 쪽으로 나갈 수 있습니다.

그래서:

socket.bind(...)

설정을 명확히 하는 게 중요합니다.

Discovery 성공 후 바로 TCP 연결하면 실패하기도 한다

이것도 꽤 흔합니다.

흐름 예시:

Discovery response 수신
→ 즉시 TCP connect
→ connection refused

왜냐하면:

DoIP announcement 가능
BUT
TCP service 아직 준비 중

상황이 있을 수 있기 때문입니다.

그래서 일부 구현은:

discovery success
→ short delay
→ TCP connect

흐름을 사용하기도 합니다.

Gateway reboot 상황도 애매하다

특히 차량 환경에서는:

IGN ON/OFF
partial reboot
network wakeup

같은 이벤트가 많습니다.

이때:

old TCP session invalid
BUT
discovery cache는 남아 있음

상황이 자주 생깁니다.

그래서 discovery cache 정책도 중요합니다.

테스트 환경과 양산 환경은 꽤 다르다

로컬 테스트에서는:

PC <-> ECU direct

구조라 단순합니다.

하지만 실제 차량은:

switch
gateway
power domain
wakeup sequence

가 다 엮입니다.

그래서 discovery timing 문제가 훨씬 잘 드러납니다.

오늘 포인트

DoIP Discovery 문제는 대부분 protocol syntax보다 timing과 network environment 문제에 가깝습니다.

실제로 중요한 건:

UDP broadcast 동작
interface 상태
gateway boot timing
retry 정책
discovery cache 관리