Posts

lwIP에서 UDP 수신 데이터가 가끔 중간에서 잘리거나 길이가 들쭉날쭉해 보이면 드라이버보다 먼저 pbuf 체인 처리 코드를 확인해야 한다. 첫 pbuf의 len만 보고 전체 길이로 오해하면 큰 프레임, 정렬 차이, pool 분할 상황에서 재현이 애매한 버그가 생긴다.

• lwIP
• pbuf
• UDP
• tot_len
• +2

DoIP에서 UDS ECU Reset 이후 연결이 살아 있는 것처럼 보이는데 다음 진단이 실패하면, ECU 애플리케이션보다 먼저 소켓 종료, Routing Activation 재수행, Tester Present 재개 순서를 확인해야 한다. reset 전후를 같은 세션으로 취급하면 ACK는 보이는데 실제 UDS가 안 붙는 식으로 쉽게 꼬인다.

• DoIP
• UDS
• ECU Reset
• Routing Activation
• +2

lwIP에서 케이블 재삽입이나 스위치 복구 뒤 링크는 살아 있는데 UDP 송신이 한동안 안 나가거나 첫 패킷만 사라지는 경우가 있다. DHCP보다 아래층인 ARP 캐시와 netif 상태 전환이 어긋나면 생기는 전형적인 증상이라, link up/down 로그와 ARP 해상도 흐름을 같이 보는 편이 빠르다.

• lwIP
• ARP
• UDP
• netif
• +2

DoIP에서 UDS 요청 후 NRC 0x21 Busy Repeat Request가 반복되면 ECU가 죽은 게 아니라 아직 같은 자원을 점유 중인 경우가 많다. timeout과 같은 정책으로 재전송하면 세션이 더 꼬일 수 있어서, 0x21 전용 retry 간격과 요청 직렬화 기준을 따로 두는 편이 안전하다.

• DoIP
• UDS
• NRC
• Busy Repeat Request
• +2

PHY 링크는 올라왔고 RX/TX 카운터도 움직이는데 lwIP DHCP가 시작되지 않거나 재연결 뒤에 IP를 다시 못 받는 경우가 있다. 대부분은 netif_set_up(), netif_set_link_up(), dhcp_start() 호출 순서와 상태 전환 타이밍 문제다. bring-up 관점에서 자주 틀리는 포인트를 정리한다.

• lwIP
• DHCP
• netif
• Link Status
• +2

DoIP에서 Routing Activation까지는 성공했는데 첫 UDS 요청만 간헐적으로 실패하면, ECU 로직보다 먼저 SA/TA와 재연결 이후 상태를 의심해야 한다. ACK/NACK, 무응답, 다른 ECU로 간 것처럼 보이는 증상을 같은 그림으로 정리한다.

• DoIP
• UDS
• Routing Activation
• Source Address
• +2

Packet Capture Command Cookbook의 tcpdump, tshark, dumpcap, udpdump 명령어 모음과 검색/필터/복사 기능, capture filter와 display filter 차이, pcap 보안 주의사항을 정리한다.

• tools.devbj.com
• Packet Capture
• tcpdump
• tshark
• +2

lwIP RAW TCP에서 전송이 몇 KB/몇 초 뒤에 멈추고 상대는 재전송만 하는데, 링크는 살아있는 경우가 있다. 대부분은 수신 콜백에서 tcp_recved()를 호출하지 않아 TCP receive window가 열리지 않는 문제다. 증상과 수정 포인트를 실무 관점으로 정리한다.

• lwIP
• TCP
• RAW API
• tcp_recved
• +2

DoIP는 UDP처럼 '패킷 단위'로 읽히지 않는다. recv() 결과를 그대로 DoIP 메시지로 간주하면 부하에서 payload length mismatch/NACK/무응답이 터진다. TCP stream 기준으로 DoIP framing을 구현하는 안전한 순서를 정리한다.

• DoIP
• TCP
• Parser
• Framing
• +2

Ethernet CRC-32 계산 결과와 실제 wire에 붙는 FCS byte order가 왜 다르게 보이는지, 0xCBF43926과 26 39 F4 CB 예제로 정리한다.

• Ethernet
• CRC32
• FCS
• Byte Order
• +1