Overview

Extremely low upload speeds on a 2.4GHz Wi-Fi network connected to an ONT are a common B2B support escalation, typically caused by one of five root causes: RF interference, channel-width misconfiguration, band-steering misbehavior, a duplex mismatch on the WAN uplink, or upstream OLT traffic shaping. Because 2.4GHz shares spectrum with Bluetooth, Zigbee, microwave ovens, and neighbouring APs, the uplink direction is far more vulnerable than the downlink, which often masks the fault during casual browsing tests. This FAQ is written for network architects, field engineers, and pre-sales technical teams who need definitive answers, CLI-level verification steps, and optical-layer diagnostics to isolate the fault within minutes rather than hours.

Frequently Asked Questions

Q1: Why is my 2.4GHz Wi-Fi upload speed on the ONT so much slower than download?

Asymmetric 2.4GHz upload slowness on an ONT is almost always caused by RF contention or a channel-width mismatch, not by the fibre itself. Unlike the downlink, the uplink requires the client station to win the CSMA/CA contention window for every single frame, so any co-channel interference, hidden-node effect, or legacy 802.11b client on the same channel disproportionately throttles upload throughput. Verify this by running a wired iperf3 test to the ONT management IP: if wired upload is at line rate but wireless upload collapses, the fault is in the 2.4GHz RF domain or the ONT's Wi-Fi radio scheduling, not in the PON or WAN path.

Q2: Which ONT settings should I check first to fix low 2.4GHz upload throughput?

The first settings to verify are channel width, band steering mode, and the Wi-Fi uplink scheduler profile on the ONT. In practice, engineers should confirm the following: (1) Channel width is set to 20MHz and not 40MHz, because 40MHz in the crowded 2.4GHz band increases retransmissions and drops upload throughput; (2) Band steering is disabled or set to a preference threshold of -70dBm or stronger, since aggressive steering can pin weak clients to 2.4GHz while starving them of airtime; (3) Airtime Fairness and MU-MIMO (if supported) are enabled to prevent one legacy client from monopolising the uplink; (4) WMM/802.11e is enabled, as disabling it forces all traffic into a single best-effort queue.

Q3: Can RF interference alone cause extremely low upload speeds on a 2.4GHz ONT network?

Yes, RF interference is the single most common cause of extremely low 2.4GHz upload speeds, and it degrades the uplink far more severely than the downlink. Because 2.4GHz only offers three non-overlapping channels (1, 6, and 11), co-channel interference raises the noise floor and forces retransmissions; each retransmission consumes additional airtime that the client must win again, so effective upload throughput can fall by 60-90%. Use a spectrum analyser or the ONT's channel-scan CLI command to identify the least-congested channel, then pin the ONT to that channel manually rather than leaving it on auto-select, which can oscillate during high-traffic periods.

Q4: How do I verify whether the bottleneck is the ONT's Wi-Fi radio or the PON uplink?

The bottleneck is confirmed to be the Wi-Fi radio if a wired Ethernet client achieves full contracted upload speed while the 2.4GHz wireless client does not. Perform a three-stage isolation test: (1) Connect a laptop via Cat6 to a LAN port on the ONT and run an upload speed test or iperf3 to a remote server; (2) Repeat the same test over 5GHz Wi-Fi; (3) Repeat over 2.4GHz Wi-Fi. If stage 1 and 2 pass but stage 3 fails, the PON, OLT, and WAN uplink are healthy and the fault lies in the 2.4GHz radio configuration, antenna path, or client driver. If stage 1 also fails, escalate to optical-layer diagnostics, checking Rx/Tx power on the ONT's PON interface.

Q5: What optical and PON-side metrics should I check if wired upload is also slow?

If wired upload is also slow, check the ONT's PON Rx power, Tx power, and upstream FEC counters, because a marginal optical link causes upstream retransmissions and traffic shaping. Acceptable Rx power for a Class B+ GPON ONT is typically between -8dBm and -27dBm, and Tx power should be between +0.5dBm and +5dBm; values outside these ranges indicate a dirty connector, a bent drop cable, or a failing splitter. In addition, inspect the OLT's DBA (Dynamic Bandwidth Allocation) profile and T-CONT assignments, since a misconfigured upstream T-CONT type can cap a subscriber's upload at a fraction of the contracted rate even when the RF link is perfect.

Q6: Does channel bonding or 40MHz mode help or hurt 2.4GHz upload performance?

Enabling 40MHz mode on 2.4GHz almost always hurts upload performance in multi-tenant or enterprise environments. While 40MHz bonding theoretically doubles the PHY rate, in the 2.4GHz band it consumes two-thirds of the available non-overlapping spectrum, dramatically increasing the probability of co-channel and adjacent-channel interference. Because upload traffic must contend for airtime on every retransmission, the higher interference level typically reduces real-world upload throughput by 30-50% compared with a clean 20MHz channel. Best practice for B2B deployments is to lock 2.4GHz to 20MHz, enable WMM, and reserve 40/80MHz operation for the 5GHz radio.

Q7: How does band steering affect 2.4GHz upload speeds, and how should it be configured?

Band steering can either improve or severely degrade 2.4GHz upload speeds depending on its threshold and hysteresis settings. When configured correctly, band steering pushes capable dual-band clients to 5GHz and leaves 2.4GHz for legacy IoT devices, which reduces contention and improves upload for the remaining 2.4GHz clients. When misconfigured with an overly aggressive threshold (for example, steering clients below -75dBm), clients may be bounced between bands mid-session, causing repeated re-association, DHCP renewals, and TCP window collapses that appear as extremely low upload speeds. Configure a steering threshold between -65dBm and -70dBm, enable 802.11k/v for assisted roaming, and disable steering entirely if the site has many single-band industrial clients.

Q8: What CLI commands can I use to diagnose 2.4GHz upload performance on the ONT?

On most carrier-grade ONTs, the following CLI commands provide the fastest diagnostic path for 2.4GHz upload issues: show wifi radio 2g status to confirm channel, width, and Tx power; show wifi clients 2g to list associated stations, their RSSI, and their negotiated MCS rates; show wifi statistics 2g to inspect retry, FCS error, and airtime utilisation counters; show pon status to verify Rx/Tx optical power and FEC errors; and show wan traffic to compare upstream throughput against the contracted rate. If airtime utilisation is consistently above 70% with a small number of clients, the problem is RF contention; if retry counters are high but airtime is low, the problem is likely client-side or antenna-related.