메뉴 바로가기본문 바로가기

[AX8004BCM] UDP 전반 및 TCP 53번 포트 순간 버스트(동시 4개 초과) 패킷 드롭 문의 추가

2026.11.13조회 4

이**AX8004BCMSKB 기가슬림

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초딜레이때문에 항상 느려지는게 너무 답답하네요

그냥 포기하고 타 공유기로 넘어가는게 정신건강에 좋은거같지만 혹시나하는 마음으로 원인해결을 알아보고있습니다.
QnA
제  목[AX8004BCM] UDP 전반 및 TCP 53번 포트 순간 버스트(동시 4개 초과) 패킷 드롭 문의 추가
이름이**
제품명AX8004BCM
인터넷 회선SKB 기가슬림
목록보기
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초딜레이때문에 항상 느려지는게 너무 답답하네요 그냥 포기하고 타 공유기로 넘어가는게 정신건강에 좋은거같지만 혹시나하는 마음으로 원인해결을 알아보고있습니다.

[2026-11-13 14:41:34]
목록보기
▲윈10 핫스팟 설정관련
▼제품 출시일 문의
챗봇 상담
설치도우미 바로가기
펌웨어 업그레이드 바로가기
펌웨어 복구도우미 바로가기
ipTIME 검색기 바로가기
EasyMesh 접속기 바로가기
ipDISK ipCloud 바로가기
ipCAM Tools 바로가기
DDNS 관리 바로가기

경기도 용인시 기흥구 죽전로 15 6층 (보정동, 벤포스타2빌딩 6층)

통신판매업신고번호 : 용인 기흥 제 388호
사업자등록번호 : 129-81-44050 | 대표자 : 김인

ALL contents are copyright 2004-EFM Networks Co
All right reserved