DevBJ 지난 글에서는 DoIP를 큰 그림으로만 봤죠.
이번엔 진짜로 프로토콜 구조 쪽으로 들어가보려 합니다.
DoIP 처음 볼 때 제일 헷갈리는 건
용어보다도 패킷을 어디서부터 읽어야 하는지인 느낌이 팍팍 옵니다.
와 이게 단순히 “이더넷 진단이다” 수준이 아니라,
실제로는 헤더부터 payload까지 순서대로 보는 감각이 필요하더라고요.
이번 글은 그쪽만 딱 봅니다.
길게 안 가고,
DoIP Generic Header,
핵심 필드 의미,
어디를 먼저 봐야 하는지
이 정도로만 정리해보겠습니다.
먼저, DoIP 패킷은 이런 틀로 본다
가장 먼저 눈에 익혀야 하는 건 이 구조입니다.
DoIP Generic Header
+------------------------+
| Protocol Version | 1 byte
+------------------------+
| Inverse Version | 1 byte
+------------------------+
| Payload Type | 2 bytes
+------------------------+
| Payload Length | 4 bytes
+------------------------+
| Payload | N bytes
+------------------------+한 문장부터 가보면 이겁니다.
DoIP는 앞에 공통 헤더가 붙고, 그 뒤 payload가 메시지 타입에 따라 달라지는 구조입니다.
즉 패킷을 볼 때
무조건 앞에서부터 순서대로 보면 됩니다.
- 버전 확인
- 반전 버전 확인
- 이 메시지가 무슨 타입인지 확인
- 길이 확인
- 그다음 payload 해석
이 순서가 기본입니다.
Protocol Version은 말 그대로 버전이다
이건 이름 그대로입니다.
현재 DoIP 프로토콜 버전을 나타내는 필드죠.
처음 보면 별거 아닌데,
실제로는 상대가 어떤 버전으로 말하고 있는지 보는 기본 정보라서 중요합니다.
패킷 볼 때 맨 앞 1바이트라
구조를 잡을 때 기준점 역할도 합니다.
Inverse Version은 왜 붙어 있냐
이 부분에서 처음에 한 번 멈칫하죠.
“버전은 알겠는데 반전 버전은 또 뭐지?”
쉽게 말하면
버전 필드를 한 번 더 검증하는 느낌으로 보면 됩니다.
즉 Protocol Version과 서로 반대값 관계를 가지도록 해서
헤더가 정상인지 빠르게 확인하는 데 도움을 줍니다.
예를 들어 이런 식이죠.
Protocol Version = 0x02
Inverse Protocol Version= 0xFD이런 구조는 실무에서 꽤 익숙합니다.
헤더 일부가 깨졌거나 해석이 꼬였을 때
이런 반전 값이 있으면 이상 여부를 빨리 감지하기 좋죠.
강력 추천합니다!
처음 패킷 볼 때는 이 필드도 같이 보는 습관을 들이면 좋습니다.
Payload Type이 진짜 핵심이다
여기서부터 패킷 성격이 갈립니다.
Payload Type은
뒤에 오는 payload가 어떤 메시지인지 알려주는 필드입니다.
즉 같은 DoIP 패킷이어도
이 값에 따라 의미가 달라집니다.
예를 들면 큰 분류만 봐도 이런 메시지들이 있죠.
- Vehicle Identification 관련
- Routing Activation 관련
- Alive Check 관련
- Diagnostic Message 관련
즉 실무에서는 패킷을 봤을 때
제일 먼저 “아 이게 무슨 용도의 패킷이구나”를 알려주는 게 Payload Type입니다.
한마디로
Payload Type은 DoIP 패킷 해석의 분기점입니다.
Payload Length는 생각보다 더 중요하다
이건 뒤 payload 길이를 나타내는 필드입니다.
말만 보면 단순하죠.
근데 실제로는 이게 꽤 중요합니다.
왜냐면 패킷 볼 때 이런 걸 바로 판단할 수 있기 때문입니다.
- 길이가 정상인가
- 실제 캡처 길이와 맞는가
- payload 해석 범위가 어디까지인가
- 잘린 패킷인지 아닌지
예를 들어 헤더는 맞는데 길이가 이상하면
뒤 해석이 전부 꼬일 수 있습니다.
그래서 저는 패킷 볼 때
Payload Type만큼이나 Payload Length도 꼭 같이 봅니다.
아주 단순한 예로 보면 이런 느낌이다
예시를 아주 단순화해서 보면 이렇습니다.
02 FD 00 05 00 00 00 0C ...이걸 RFC 느낌으로 끊어보면:
+------------------------+
| 0x02 | Protocol Version
+------------------------+
| 0xFD | Inverse Version
+------------------------+
| 0x0005 | Payload Type
+------------------------+
| 0x0000000C | Payload Length
+------------------------+
| ... | Payload
+------------------------+이런 식으로 보면 훨씬 덜 무섭습니다.
처음엔 hex만 길게 보면 머리가 아픈데,
필드 단위로 끊어보면
“아 앞 8바이트는 공통 헤더구나”
이 감각이 생깁니다.
그래서 패킷을 실제로 볼 때는 뭘 먼저 보냐
저는 보통 이 순서로 봅니다.
1) Protocol Version / Inverse Version
헤더가 정상 구조인지 먼저 봅니다.
2) Payload Type
이 패킷이 무슨 목적의 메시지인지 확인합니다.
3) Payload Length
길이가 정상인지 확인합니다.
4) Payload 해석
이제 메시지 타입에 맞춰 뒤 payload를 봅니다.
이 순서가 좋은 이유는 단순합니다.
앞 헤더가 이상한데 뒤를 열심히 읽어봐야 시간만 날리거든요.
정말로 말이야,
패킷 분석은 앞에서부터 보는 습관이 중요합니다.
메시지 타입별 payload는 왜 다음 단계로 미뤄야 하냐
여기서 욕심내면 한 글이 너무 길어집니다 ^^;;
Payload Type까지만 봐도
뒤에 해석할 구조가 꽤 갈리기 때문이죠.
예를 들어 payload는 타입에 따라 전혀 성격이 달라집니다.
- Vehicle Identification이면 식별 정보 쪽
- Routing Activation이면 활성화 요청/응답 쪽
- Alive Check면 연결 상태 확인 쪽
- Diagnostic Message면 실제 진단 데이터 쪽
즉 공통 헤더까지는 같은데,
그 뒤는 메시지 성격에 따라 갈라집니다.
그래서 이번 글은
공통 헤더를 읽는 감각까지만 잡는 게 맞습니다.
나쁜 접근 vs 좋은 접근
이것도 차이가 큽니다.
나쁜 접근
- hex dump 전체를 한 번에 보려 함
- Payload Type 확인 안 하고 뒤부터 읽음
- 길이 체크 없이 payload 해석 시작
- 버전 필드를 무시함
좋은 접근
- 공통 헤더부터 끊어봄
- Protocol Version / Inverse Version 확인
- Payload Type으로 분기
- Payload Length 확인 후 payload 해석
패킷 분석은 이런 기본 순서만 잡아도
헷갈림이 확 줄어듭니다.
실무에서 제일 먼저 익숙해져야 하는 건 “헤더 8바이트”다
이 글에서 진짜 핵심은 이겁니다.
DoIP를 보다가 복잡해지는 이유 중 하나가
payload 구조까지 한 번에 다 보려 하기 때문입니다.
근데 실제로는
앞 8바이트 Generic Header부터 익숙해지는 게 먼저입니다.
+------------------------+
| Protocol Version | 1 byte
+------------------------+
| Inverse Version | 1 byte
+------------------------+
| Payload Type | 2 bytes
+------------------------+
| Payload Length | 4 bytes
+------------------------+이거만 눈에 익어도
패킷을 볼 때 훨씬 덜 막막해집니다.
며칠 밤을 새웠던 기억까지는 아니지만 ^^;;
저도 프로토콜 볼 때 처음부터 payload 세부 필드 다 외우려다가 더 헷갈렸던 적이 있습니다.
오히려 공통 헤더부터 손에 익히는 쪽이 훨씬 빨랐습니다.
다음 글에서는 뭘 보면 좋냐
여기까지 왔으면 그다음은 자연스럽습니다.
다음엔 이런 쪽으로 더 들어가면 됩니다.
- Vehicle Identification payload 구조
- Routing Activation request / response 구조
- Diagnostic Message payload 구성
- 실제 캡처 예시 기반 해석
즉 이제부터는
“공통 헤더 뒤에 각 메시지 타입이 어떻게 붙는지”
그걸 보면 됩니다.
추천 대상
- DoIP 패킷 구조를 처음 보는 분
- Wireshark나 hex dump를 볼 때 어디부터 읽어야 할지 헷갈리는 분
- Protocol Version, Payload Type, Payload Length 의미를 먼저 정리하고 싶은 분
- DoIP 1편 큰 그림은 잡았고, 이제 구조 쪽으로 넘어가려는 분
- UDS보다 DoIP 헤더 구조가 더 낯선 분
한 줄 요약
DoIP 패킷은 공통 헤더 8바이트부터 읽고, 그다음 Payload Type과 Length를 기준으로 payload를 해석하면 훨씬 정리가 잘 된다.
추천 키워드
DoIP 헤더, DoIP 프로토콜 구조, DoIP Payload Type, DoIP Payload Length, DoIP Generic Header, Automotive Ethernet, DoIP 패킷 분석, UDS on DoIP, 차량 진단 프로토콜, DoIP 필드 설명