[AX8004BCM] UDP 전반 및 TCP 53번 포트 순간 버스트(동시 4개 초과) 패킷 드롭 문의 추가
https://iptime.com/support/qna/900658
이여서 질문드립니다.
1. 펌웨어 내부 코드 전수 분석 결과
① iptables(리눅스 방화벽) 룰 분석 결과: "iptables 룰이 아니다!" 펌웨어 내부의 방화벽 룰 제어 파일인 nfrule.json, libnfrule.so, libesysapi.so를 모두 추출하여 디컴파일 및 스트링 전수 조사를 진행했습니다. 조사 결과, iptables 방화벽에는 당초 가설로 생각했던 -m limit --limit-burst 4 같은 명시적인 텍스트 방화벽 규칙이 존재하지 않았습니다. (웹 UI에서 제어하는 forward_dos, xt_connlimit.ko 등만 들어있었습니다.)
② 진짜 원인 적발: "브로드컴 하드웨어 가속 드라이버(Runner/RDPA)의 큐 병목" 방화벽보다 더 밑단인 커널 모듈 드라이버(bcm_enet.ko, rdpa.ko, bcm_ingqos.ko, pktrunner.ko) 내부 바이너리를 분석한 결과, 결정적인 증거를 찾아냈습니다:
text
[bcm_enet.ko & bcm_ingqos.ko 드라이버 내부 심볼]
- rdpa_egress_tm_queues_cfg
- enet_swqueue (ENET Software Queue)
- iqos_fap_ethRxDqmQueue (하드웨어 DQM 큐 및 loThr, hiThr, dropped, cong 카운터)
- configure_bc_rate_limit_meter
- blog_finit return PKT_DROP
원인 분석 및 기술적 의견
공식 펌웨어(16.00.8) 내부 분석 결과, iptables 방화벽 레벨에는 limit-burst 같은 별도의 룰이 존재하지 않았습니다. 따라서 이 현상은 방화벽 정책이 아니라 Broadcom HND 커널 드라이버(bcm_enet.ko / rdpa.ko / bcm_ingqos.ko) 레벨에서 발생하는 것으로 보입니다. 하드웨어 가속(Runner)에 아직 등록되지 않은 초기 UDP 버스트나 감시 대상 포트(53번)가 CPU 슬로우 패스로 전달될 때, 드라이버의 호스트 수신 큐(DQM Queue / Software Ring Buffer)의 깊이(Queue Depth)가 4개 수준으로 극도로 작게 설정되어 있어 순간 버스트 시 드라이버 단에서 즉시 드롭(PKT_DROP)되는 것으로 파악됩니다.
요청 사항
일반 웹서핑(TCP 443)은 문제가 없으나, 리눅스 서버 환경의 glibc A/AAAA 병렬 DNS 질의나 멀티스레드 UDP 통신 환경에서는 5초 타임아웃 및 초기 접속 딜레이가 빈번하게 발생하고 있습니다. Broadcom bcm_enet / rdpa 드라이버 단의 Slow-path CPU 수신 큐(SW Queue / Ingress Buffer) 크기를 상향 조정(예: 16~32 이상)하여 패킷 드롭을 완화해 주실 수 있는지 검토를 부탁드립니다.
AI 가 리버싱 해준결과라 정확성은 모르겠습니다.
나름 고가의 공유기인데 5초딜레이때문에 항상 느려지는게 너무 답답하네요
그냥 포기하고 타 공유기로 넘어가는게 정신건강에 좋은거같지만 혹시나하는 마음으로 원인해결을 알아보고있습니다.
이여서 질문드립니다.
1. 펌웨어 내부 코드 전수 분석 결과
① iptables(리눅스 방화벽) 룰 분석 결과: "iptables 룰이 아니다!" 펌웨어 내부의 방화벽 룰 제어 파일인 nfrule.json, libnfrule.so, libesysapi.so를 모두 추출하여 디컴파일 및 스트링 전수 조사를 진행했습니다. 조사 결과, iptables 방화벽에는 당초 가설로 생각했던 -m limit --limit-burst 4 같은 명시적인 텍스트 방화벽 규칙이 존재하지 않았습니다. (웹 UI에서 제어하는 forward_dos, xt_connlimit.ko 등만 들어있었습니다.)
② 진짜 원인 적발: "브로드컴 하드웨어 가속 드라이버(Runner/RDPA)의 큐 병목" 방화벽보다 더 밑단인 커널 모듈 드라이버(bcm_enet.ko, rdpa.ko, bcm_ingqos.ko, pktrunner.ko) 내부 바이너리를 분석한 결과, 결정적인 증거를 찾아냈습니다:
text
[bcm_enet.ko & bcm_ingqos.ko 드라이버 내부 심볼]
- rdpa_egress_tm_queues_cfg
- enet_swqueue (ENET Software Queue)
- iqos_fap_ethRxDqmQueue (하드웨어 DQM 큐 및 loThr, hiThr, dropped, cong 카운터)
- configure_bc_rate_limit_meter
- blog_finit return PKT_DROP
원인 분석 및 기술적 의견
공식 펌웨어(16.00.8) 내부 분석 결과, iptables 방화벽 레벨에는 limit-burst 같은 별도의 룰이 존재하지 않았습니다. 따라서 이 현상은 방화벽 정책이 아니라 Broadcom HND 커널 드라이버(bcm_enet.ko / rdpa.ko / bcm_ingqos.ko) 레벨에서 발생하는 것으로 보입니다. 하드웨어 가속(Runner)에 아직 등록되지 않은 초기 UDP 버스트나 감시 대상 포트(53번)가 CPU 슬로우 패스로 전달될 때, 드라이버의 호스트 수신 큐(DQM Queue / Software Ring Buffer)의 깊이(Queue Depth)가 4개 수준으로 극도로 작게 설정되어 있어 순간 버스트 시 드라이버 단에서 즉시 드롭(PKT_DROP)되는 것으로 파악됩니다.
요청 사항
일반 웹서핑(TCP 443)은 문제가 없으나, 리눅스 서버 환경의 glibc A/AAAA 병렬 DNS 질의나 멀티스레드 UDP 통신 환경에서는 5초 타임아웃 및 초기 접속 딜레이가 빈번하게 발생하고 있습니다. Broadcom bcm_enet / rdpa 드라이버 단의 Slow-path CPU 수신 큐(SW Queue / Ingress Buffer) 크기를 상향 조정(예: 16~32 이상)하여 패킷 드롭을 완화해 주실 수 있는지 검토를 부탁드립니다.
AI 가 리버싱 해준결과라 정확성은 모르겠습니다.
나름 고가의 공유기인데 5초딜레이때문에 항상 느려지는게 너무 답답하네요
그냥 포기하고 타 공유기로 넘어가는게 정신건강에 좋은거같지만 혹시나하는 마음으로 원인해결을 알아보고있습니다.






































