Posts
All the articles I've posted.
-
lwIP TCP 버퍼 설정 읽는 법: TCP_SND_BUF, TCP_WND, MEM_SIZE, MEMP_NUM_TCP_SEG, PBUF_POOL_SIZE
lwIP의 TCP_SND_BUF, TCP_WND, MEM_SIZE, MEMP_NUM_TCP_SEG, PBUF_POOL_SIZE가 각각 어떤 병목을 만들고 어떤 메모리 예산과 연결되는지 일반화된 예시로 정리한다.
-
lwIP RAW UDP callback 뒤에 수신이 멈춘다: pbuf_free를 놓치면 PBUF_POOL이 먼저 마른다
lwIP에서 UDP는 처음엔 잘 되는데 몇 분 뒤부터 recv callback이 끊기거나 pbuf_alloc 실패가 보이면, 드라이버보다 먼저 RAW UDP callback에서 pbuf_free를 빠뜨린 경로를 확인해야 한다. 작은 누수 하나가 PBUF_POOL 고갈로 이어져 전체 RX 경로를 막을 수 있다.
-
DoIP에서 Response Pending 중 Tester Present를 섞으면 꼬인다: 같은 세션 유지와 대기 흐름을 분리해서 봐야 한다
DoIP에서 긴 UDS 작업 중 NRC 0x78 Response Pending이 오는 동안 Tester Present를 같은 소켓과 같은 요청 흐름에 무심코 섞어 보내면, 대기 중인 서비스 응답과 keepalive 목적의 세션 유지 요청이 충돌해 로그 해석과 재시도 정책이 쉽게 꼬인다. 두 흐름을 분리해 관리하는 편이 안전하다.
-
-
Wireshark Reassembled TCP Segments 의미: 여러 TCP 조각이 하나의 메시지로 보일 때
Wireshark의 Reassembled TCP Segments 메시지가 의미하는 것과 TCP sequence number, 상위 계층 PDU length, reassembly 옵션 기준을 예제로 설명한다.
-
lwIP에서 RX는 되는데 payload가 가끔 깨진다: DMA 버퍼와 D-Cache 순서를 같이 봐야 한다
lwIP 포팅에서 링크는 정상이고 인터럽트도 도는데 UDP payload나 ARP 내용이 가끔 깨져 보이면, pbuf보다 먼저 DMA 버퍼와 CPU D-Cache 일관성을 확인해야 한다. RX 전 invalidate, TX 후 clean 순서가 어긋나면 랜덤 패킷 손상처럼 보이는 증상이 반복된다.
-
DoIP에서 UDS를 ISO-TP처럼 자르면 안 된다: Diagnostic Message 경계를 먼저 봐야 한다
DoIP에서 UDS 요청이 길어질 때 CAN의 ISO-TP처럼 프레임을 쪼개어 처리하려 들면 길이 계산, 재전송, 응답 매칭이 쉽게 꼬인다. DoIP는 TCP stream 위에서 Generic Header의 payload length로 메시지 경계를 잡고, UDS 한 요청을 Diagnostic Message 단위로 다루는 편이 안전하다.
-
lwIP TCP 재시도 루프에서 RTOS delay가 필요한 이유: busy loop를 막고 CPU를 양보하기
lwIP 같은 RTOS 기반 TCP/IP stack에서 송신 재시도 루프를 아무 대기 없이 반복하면 busy loop가 되어 오히려 네트워크 thread와 다른 task의 실행을 방해할 수 있다. 짧은 RTOS delay와 timeout을 함께 두면 CPU 양보와 무한 대기 방지를 동시에 챙길 수 있다.
-
lwIP에서 tcpip_thread 안에서 다시 기다리면 멈춘다: callback 안의 netconn/sockets 호출이 self-deadlock이 되는 이유
lwIP에서 tcpip_callback, netif callback, 내부 이벤트 훅 안에서 netconn 또는 sockets API를 다시 호출하면 부하가 낮을 때는 지나가도 어느 순간 전체 네트워크가 멈출 수 있다. 같은 tcpip_thread가 자기 자신에게 일을 보내고 완료를 기다리는 self-deadlock 패턴이라, 호출 컨텍스트를 분리해 두는 편이 안전하다.
-
DoIP에서 Security Access 뒤 NRC 0x24가 뜬다: seed/key 이후 요청 순서와 세션 문맥을 같이 봐야 한다
DoIP에서 Security Access 자체는 되는 것 같은데 unlock 직후 요청이 NRC 0x24 Request Sequence Error로 실패하면, key 계산보다 먼저 seed/key 순서와 세션 문맥이 유지됐는지 봐야 한다. 재연결, 세션 전환, 병렬 요청이 끼면 같은 ECU라도 이전 unlock 흐름이 쉽게 무효화된다.
-
lwIP에서 UDP 길이가 가끔 잘못 읽힌다: pbuf 체인에서는 len 말고 tot_len을 봐야 한다
lwIP에서 UDP 수신 데이터가 가끔 중간에서 잘리거나 길이가 들쭉날쭉해 보이면 드라이버보다 먼저 pbuf 체인 처리 코드를 확인해야 한다. 첫 pbuf의 len만 보고 전체 길이로 오해하면 큰 프레임, 정렬 차이, pool 분할 상황에서 재현이 애매한 버그가 생긴다.