Codex SSHd into my router and found an extra 1 Gbps I didn't know I was

A home network administrator using an AI assistant over SSH resolved a persistent throughput ceiling on an Intel-based pfSense firewall, recovering an unutilized gigabit of bandwidth on a 2 Gbps Orange fiber connection. According to notes.ciechanowi.cz's report, the investigation into why a wired PC on a 2.5 Gbps local network scored roughly the same as a wireless mesh connection bypassed physical cabling assumptions entirely. Instead of replacing hardware, a read-only remote inspection of FreeBSD kernel queues and packet capture listeners uncovered software-level processing limits directly restricting throughput.

This report examines how diagnosing network stack bottlenecks in open-source router software can resolve hidden speed caps on multi-gigabit broadband tiers. It details the exact diagnostic commands, sysctl adjustments, and service modifications required to untangle FreeBSD packet queues without hardware upgrades. The breakdown is targeted at network engineers, home lab administrators, and systems operators managing bare-metal pfSense installations across high-throughput symmetrical links who face unexpected throughput degradation despite proper physical port autonegotiation.

Codex SSHd into my router and found an extra: what actually changed

The inspection started on a bare-metal firewall appliance powered by an Intel Celeron N4000 processor, approximately 8 GB of RAM, and Intel I226-V Ethernet controllers managed by FreeBSD's igc driver running pfSense CE 2.8.1. Initial link queries using ifconfig for interfaces igc0 on the WAN and igc1 on the LAN confirmed that both ports actively negotiated 2500Base-T full-duplex with an upstream Orange Funbox gateway. Netstat output showed zero cyclic redundancy check errors, zero receive overruns, and no NIC watchdog timeouts, eliminating common physical cable faults. However, the diagnostic command netstat -B revealed eight active bandwidthd Berkeley Packet Filter readers attached to the LAN interface across two separate process trees, alongside an IPv4 software interrupt queue counter showing 32,126 accumulated drop events.

To eliminate packet starvation, the administrator disabled the bandwidthd monitoring service entirely and reconfigured the kernel interrupt queue ceiling via sysctl. The key parameter net.inet.ip.intr_queue_maxlen was doubled from its default ceiling of 1,000 packets up to 2,000 packets per workstream. Subsequent throughput verification demonstrated that the wired desktop achieved its full 2 Gbps service rate without changing network interface cards or adjusting the existing dual-queue MSI-X hardware allocations. The administrative adjustments proved that packet loss was occurring within the kernel software queues rather than at the physical Ethernet layer or within the upstream fiber termination equipment.

Codex SSHd into my router and found an extra: how it works

Packet delivery across FreeBSD relies on the netisr subsystem to balance ingress processing across available central processing unit cores. On the dual-core Celeron N4000 platform, the system exposes two independent IPv4 workstream queues, allocating one queue per CPU core rather than drawing from a shared global memory pool. When incoming traffic bursts arrive faster than a core can process them, packets wait inside the queue defined by net.inet.ip.intr_queue_maxlen. If an enqueued packet arrives when the workstream buffer reaches capacity, the FreeBSD kernel immediately frees the network buffer, registers an ENOBUFS error, and increments the accumulated net.inet.ip.intr_queue_drops counter, discarding the data before transport layer handling.

Concurrently, packet filter readers introduce sustained processing tax across interface boundaries. Each Berkeley Packet Filter listener attached to igc1 receives an independent copy of incoming traffic streams, forcing the system to duplicate packets and parse filters for every attached monitoring process. Running eight bandwidthd capture readers forced the low-power CPU to replicate ingress frames repeatedly, competing directly with routine routing operations. Disabling the monitoring daemon eliminated this duplicate memory processing, while doubling the queue depth to 2,000 packets provided sufficient buffer space during bursty speed tests, allowing CPU 1 to hold 1,316 packets simultaneously without dropping frames.

Codex SSHd into my router and found an extra: why it matters

Nominal Ethernet negotiation indicators often mask underlying operating system bottlenecks during high-bandwidth data transfers. While a network interface controller may report an active 2.5 Gbps connection, that status merely reflects physical signal synchronization rather than real-world packet forwarding throughput. When an operating system input queue drops packets, reliable protocols like TCP suffer severe throughput degradation because packet loss triggers congestion control algorithms. The transmitting endpoint interprets missing acknowledgments as network congestion, cutting its congestion window, retransmitting segments via fast retransmit, and reducing the total volume of unacknowledged data in flight across the connection.

These transport layer retries explain how an administrative bottleneck can restrict an entire 2 Gbps Internet pipeline down to roughly 1 Gbps without dropping the underlying network connection. Because TCP repairs missing segments automatically without crashing application sessions, users rarely notice outright disconnections, observing only reduced speed test benchmarks. Identifying that packet discards stem from software queue constraints rather than hardware limitations saves administrators from unnecessary equipment replacements. Furthermore, distinguishing between monitor capture buffer drops and true kernel input drops ensures that engineering teams address the actual network path rather than chasing benign monitoring anomalies.

Codex SSHd into my router and found an extra: who is affected

This bottleneck directly impacts home lab users and small office deployments running pfSense CE 2.8.1 or related FreeBSD network appliances on low-power Intel Celeron or Atom architectures with multi-gigabit connections. Users pairing 2.5GbE network switches with Intel I226-V or I225-V controllers across ISP connections exceeding 1 Gbps are especially susceptible if default kernel queue parameters remain unmodified. Systems running secondary traffic auditing packages, such as bandwidthd, ntopng, or intrusion detection agents that spawn multiple Berkeley Packet Filter readers, introduce significant CPU overhead that disproportionately degrades forwarding performance on dual-core hardware configurations.

Organizations utilizing basic gigabit broadband connections typically remain unaffected because default 1,000-packet queue limits accommodate standard traffic rates without overflowing netisr buffers. Similarly, enterprise routing hardware with high-frequency multi-core processors often clears packet queues rapidly enough to prevent drops, masking inefficient BPF configurations. The failure mode remains concentrated among users upgrading their external broadband tiers past 1 Gbps while retaining legacy entry-level appliances, where default operating system queue thresholds fail to absorb transient microbursts generated by modern high-speed file transfers and multi-stream download benchmarks.

Codex SSHd into my router and found an extra: what to watch

Administrators running FreeBSD-based routing stacks should monitor their input queue health rather than relying strictly on top-level CPU utilization graphs. Deploying an operational monitoring shell script that repeatedly reads net.inet.ip.intr_queue_drops alongside netstat -Q provides clear visibility into workstream queue lengths, high-water marks, and active overflow events. Tracking per-CPU queue lengths reveals whether specific workstreams approach configured ceilings during peak traffic windows. If the delta counter for drop events climbs while high-water marks match net.inet.ip.intr_queue_maxlen, increasing the sysctl parameter in Netgate's pfSense system tunables provides immediate buffer relief for bursty ingress transfers.

Network teams must also evaluate the operational cost of auxiliary software packages running directly on firewall appliances. Reviewing active packet sockets using netstat -B exposes how many background processes inspect raw traffic on production interfaces, ensuring monitoring tools do not quietly consume forwarding capacity. Moving forward, administrators managing multi-gigabit links must balance queue expansion against bufferbloat, ensuring that larger queue limits accommodate transient scheduling latency without introducing persistent round-trip latency under sustained saturation across production gateway environments.