From 80 Mbps and Random 100 Mbps Links to a Proven 720 Mbps Wi-Fi Path

This is Part 1 of a troubleshooting series built from a real incident rather than a clean-room example. This post keeps the chronological investigation: what looked broken, what actually was broken, the tests that misled me, and the measurements that finally narrowed the fault domain. Part 2 will extract the reusable command runbook; Part 3 will preserve the evidence ledger and restart point.

For publication, private addressing, VLAN numbers, endpoint names, and location-specific labels have been replaced with documentation networks and generic names. Device models and measured results that matter to the diagnosis are retained.

The original symptom looked simple: internet performance at the remote site was only around 80 Mbps, even though the path should have been capable of several hundred megabits per second.

The path was approximately:

remote client
  → wired Ethernet or U6 Wi-Fi
  → remote-site Juniper EX3300
  → passive-PoE injector
  → remote-site PowerBeam
  )) 5 GHz point-to-point bridge ((
  → core-site PowerBeam
  → router / core network
  → core-side test server or internet

The eventual fix was not one magic setting. There were multiple overlapping problems, and the useful progress came from shortening the path until each section could be measured independently.

Cisco’s general system-troubleshooting guidance describes the same bottom-up habit: start with the physical path, then Layer 2 state, then Layer 3 routing, and only move upward when the lower layers are credible.¹

1. Establish the symptom, but do not let Speedtest define the fault

The first observation was about 80 Mbps of internet throughput.

That established that something was wrong. It did not establish where.

An internet speed test includes too much:

client radio or NIC
→ AP or switch
→ EX3300
→ PoE injector
→ PowerBeam Ethernet
→ PowerBeam RF bridge
→ core router
→ ISP
→ remote speed-test server

A poor result at the end of that chain can be caused by any of those segments.

I split testing into two categories:

• Internet speed tests for the user-visible result.
• iperf3 between controlled endpoints for path isolation.

The basic iperf3 server was:

iperf3 -s

A normal 30-second client test:

iperf3 -c "$SERVER" -t 30 -O 3

Reverse the data direction:

iperf3 -c "$SERVER" -R -t 30 -O 3

And test four parallel TCP streams:

iperf3 -c "$SERVER" -P 4 -t 30 -O 3
iperf3 -c "$SERVER" -P 4 -R -t 30 -O 3

In iperf3, normal mode sends client → server. -R reverses the test so the server sends to the client, while -P 4 creates four parallel streams.²

That moved the question from:

Why is the internet slow?

to:

Which direction is slow?
Which segment is slow?
Does the fault follow a physical path or an application role?

OSI focus: Layer 4 measurement over a path that still depends on Layers 1–3.

2. The first confirmed Layer-1 fault was a 100 Mbps PoE injector

The first concrete problem was embarrassingly physical: one passive-PoE injector in the bridge path supported only 100 Mbps Ethernet.

That immediately explained why the original result clustered around Fast Ethernet speeds.

Replacing it with a gigabit-capable passive-PoE injector allowed initial throughput in roughly the 400–500 Mbps range.

No routing change, Wi-Fi setting, queue adjustment, or TCP tuning could have worked around a component physically limited to 100 Mbps.

But the story did not end there.

After replacement, the Ethernet side initially negotiated at 1 Gbps and passed several hundred megabits per second. Later, the remote-side link dropped and came back at 100 Mbps. Disconnecting and reconnecting the injector’s LAN-side cable restored 1 Gbps.

That changed the investigation from “wrong injector” to “something in this copper channel is marginal.”

The path under suspicion became:

EX3300 port
→ short patch cable
→ coupler / patch panel
→ injector LAN jack
→ injector internals
→ injector PoE jack
→ outdoor cable
→ PowerBeam Ethernet PHY

Gigabit autonegotiation is not just a cosmetic status field. Cisco’s Ethernet documentation notes that Gigabit Ethernet negotiation includes parameters such as duplex and optional flow control/PAUSE behavior.³

A link that repeatedly changes from 1000 Mbps to 100 Mbps is therefore evidence worth preserving before touching anything.

OSI focus: Layer 1, with Layer-2 negotiation consequences.

3. The coupler panel convicted itself through A/B testing

The bridge path included a cheap six-port female-to-female “Cat6A” patch panel. It was not a conventional punch-down panel; it was effectively a row of inline RJ45 couplers.

Removing it initially helped.

More importantly, putting it back repeatedly recreated the fault.

Panel inserted:
  throughput degrades
  severe directional asymmetry appears
  link eventually renegotiates to 100 Mbps

Panel bypassed:
  link returns to 1000 Mbps
  wired bridge throughput returns to roughly 400/400 Mbps

At one point, the panel-present path was as asymmetric as roughly 13 Mbps in one direction and 400 Mbps in the other.

That repeatability mattered more than any single counter snapshot.

A passive component does not need to look damaged to make a Gigabit Ethernet channel marginal. Contact quality, pair geometry, termination, or an intermittent connection can be enough to make negotiation unstable.

The practical conclusion was straightforward:

Reinserting the coupler panel repeatedly recreated the failure; bypassing it repeatedly restored 1 Gbps negotiation and several-hundred-megabit throughput.

The panel came out of the bridge path.

Why zero CRC errors did not clear it

At one observation point, the EX3300 did not show an obvious wall of CRC or input errors.

That was useful, but it was not exonerating.

A marginal link can:

• fail negotiation and fall back to 100 Mbps;
• flap and recover between observations;
• have counters reset or be inspected after the event;
• create downstream TCP loss without continuously incrementing one specific switch counter;
• temporarily recover after reseating.

For a recurrence, the valuable Junos capture is taken before touching the cable:

show interfaces ge-0/0/X extensive | no-more
show interfaces ge-0/0/X media | no-more
show interfaces ge-0/0/X extensive | match "flap|error|carrier|pause|CRC|drop"

Junos defines Carrier transitions as down-to-up transitions and specifically treats rapidly increasing transitions as a clue to cable, far-end, or interface problems.⁴

The procedural lesson was bigger than this one panel:

Reseating a cable can fix the symptom while destroying the evidence.

OSI focus: Layer 1 physical channel, observed through Layer-2 link/error state.

4. Reverse iperf3 exposed a failure Speedtest could not explain

With the unstable path, the remote wired client could send toward the core-side test server at roughly 430 Mbps.

The reverse direction was catastrophic.

A representative completed run was:

18.1 Mbits/sec
3753 TCP retransmissions
congestion window collapsing to only a few kilobytes

Four parallel streams improved aggregate throughput only to roughly 22.5 Mbps, while retransmissions remained massive.

This did not look like a clean fixed-rate ceiling.

If the problem were simply “this path is 100 Mbps,” both directions would usually be constrained in roughly the same range. Instead, one physical direction was several hundred megabits per second while the other collapsed below 20 Mbps.

The TCP evidence mattered too. The retransmissions and tiny congestion window showed TCP repeatedly backing off because it experienced the path as severely lossy or congested.

I also moved the iperf3 client/server roles between endpoints.

The bad result followed the physical data direction, not whichever machine happened to run iperf3 -c.

That distinction matters:

-R changes who sends the test data.
Moving the client process changes the control endpoint.
The physical sender/receiver direction is the evidence that matters.

OSI focus: Layer 4 symptoms exposing a likely lower-layer impairment.

5. A temporary wired-client condition complicated the story

Later, I moved the remote endpoint from wired Ethernet to Wi-Fi through the same U6 and EX3300.

Core → remote Wi-Fi produced roughly 209 Mbps in a single stream with only modest retransmission.

That path still included:

core test server
→ core network/router
→ PowerBeam bridge
→ remote EX3300
→ U6
→ Wi-Fi client

It was not a perfect result, but it was dramatically better than the earlier 18–22 Mbps wired result through the same bridge.

That meant the PowerBeam RF path alone could not explain the extreme one-way collapse.

When I returned to the wired endpoint later, the path had recovered to approximately 418 Mbps in a single stream, with multi-stream tests also above 400 Mbps.

Something in this shorter path had changed state:

wired client NIC
→ client patch cable
→ EX3300 client port

Possible mechanisms included:

• NIC or driver state;
• Energy Efficient Ethernet state;
• PAUSE/flow-control interaction;
• marginal client patch cable;
• switch-port state;
• a PHY reset caused by reconnecting or changing interfaces.

I did not claim which of those had happened because I did not capture the decisive evidence while the fault was active.

For the next recurrence, the prepared Linux checks are:

doas ethtool IFACE
doas ethtool --show-eee IFACE
doas ethtool -S IFACE | grep -Ei 'crc|error|drop|miss|pause|timeout|reset|carrier'
ip -s link show dev IFACE

This did not weaken the coupler-panel conclusion. It showed that more than one fault or temporary state had existed during the same troubleshooting session.

OSI focus: Layers 1 and 2, visible through Layer-4 behavior.

6. Continuous ping established a latency baseline

I ran a rapid ping during some of the throughput tests:

ping -i 0.1 "$SERVER"

One longer run recorded:

1371 packets transmitted
1366 received
0.364697% packet loss
rtt min/avg/max/mdev = 0.804/4.056/113.599/8.950 ms

Most latency was only a few milliseconds, but there were occasional spikes above 100 ms and a small amount of packet loss.

That did not identify a failing component.

It did establish context:

• normal path latency was low;
• the network was not permanently high-latency;
• transient loss or queueing events existed;
• the 18 Mbps TCP collapse was not just a consistently slow routed path.

Ping was supporting evidence, not the diagnosis.

OSI focus: Layer 3 visibility influenced by lower-layer loss and queueing.

7. The U6 looked slow until PHY rate and throughput were separated

The next suspect became the UniFi U6.

Early observations had been described as:

Wi-Fi 5 laptop: 400/400
mobile client: 286/286

Those turned out to be UniFi RX/TX PHY rates, not application throughput.

Measured throughput was lower:

• Wi-Fi 5 laptop: roughly 200–250 Mbps
• mobile client: roughly 190 Mbps

Ubiquiti explicitly distinguishes the current PHY rate shown by UniFi from actual application throughput; protocol overhead and airtime behavior mean the real payload rate will be lower.⁵

The U6 had also been using a narrower 5 GHz channel. Changing to 80 MHz increased measured download by roughly 100 Mbps, although the combined end-to-end path still showed lower upload.

Ubiquiti recommends 80 MHz on 5 GHz when the objective is maximum throughput and the RF environment allows it.⁵

That was an improvement, but it did not yet prove whether the AP itself was the bottleneck.

OSI focus: Layer 1 radio parameters and Layer-2 airtime behavior.

8. Linux iw showed that the client radio was not simply capped at 200 Mbps

The Wi-Fi 5 test laptop’s live association was inspected directly:

iw dev WIFI_IFACE link
iw dev WIFI_IFACE station dump

Representative samples included:

signal: -48 dBm
rx bitrate: 433.3 MBit/s VHT-MCS 9 80MHz VHT-NSS 1
tx bitrate: 780.0 MBit/s VHT-MCS 8 80MHz VHT-NSS 2

and:

signal: -47 dBm
signal avg: -44 dBm
tx bitrate: 650.0 MBit/s ... VHT-NSS 2
rx bitrate: 390.0 MBit/s ... VHT-NSS 1
tx failed: 0

From the laptop’s point of view:

• rx bitrate is AP → laptop;
• tx bitrate is laptop → AP;
• signal was strong;
• transmit was operating with two spatial streams;
• receive was temporarily showing one spatial stream.

That killed one early hypothesis: the laptop’s transmit radio was not simply stuck near 200 Mbps.

A useful live monitor is:

watch -n 0.5 'iw dev WIFI_IFACE link | grep -E "signal:|rx bitrate:|tx bitrate:"'

Power-save state was also prepared as a controlled variable:

iw dev WIFI_IFACE get power_save
doas iw dev WIFI_IFACE set power_save off

But I still needed a test that removed the PowerBeam from the data path entirely.

OSI focus: Layer 1 radio rate and signal exposed through station statistics.

9. My first two “local AP tests” were wrong

To prove the U6, both endpoints had to be local to the remote site and the data path had to exclude the PowerBeam and core router.

That sounds obvious in hindsight. I managed to get it wrong twice.

Mistake 1: both endpoints were wireless

The first local test used two clients associated to the same U6.

Results were roughly:

• 241 Mbps one direction;
• 193 Mbps reverse;
• around 231 Mbps in one four-stream run.

But the payload crossed the same Wi-Fi channel twice:

wireless client A
→ U6 receives over 5 GHz
→ U6 retransmits over 5 GHz
→ wireless client B

That is a useful client-to-client test. It is not a clean measurement of one wireless hop.

Shared airtime matters. Ubiquiti’s airtime guidance notes that channel competition and interference can produce lower throughput, dropped traffic, and latency.⁶

Mistake 2: one endpoint was on the wrong subnet

The next test used:

wired endpoint: 198.51.100.13
Wi-Fi endpoint: 192.0.2.8

Those are documentation addresses in this public version, but the important point is that the endpoints were in different VLANs/subnets.

The connection itself exposed the error:

local 198.51.100.13 connected to 192.0.2.8

The EX3300 was not routing between those networks locally.

The actual path became:

wired endpoint on TEST_VLAN
→ remote EX3300
→ PowerBeam to core
→ core router routes TEST_VLAN ↔ USER_VLAN
→ PowerBeam back to remote site
→ remote EX3300
→ U6
→ Wi-Fi endpoint on USER_VLAN

I had built a routed hairpin that crossed the bridge twice while believing I was testing only the AP.

Throughput dropped from roughly 45 Mbps toward the 10–30 Mbps range.

That was not proof that the U6 was slow. It was proof that I had tested the wrong path.

Before any isolation test, verify route and source selection:

ip route get "$SERVER"

For the real local AP test, both endpoints needed to live in the same local VLAN/subnet so the EX3300 could switch the frames directly without involving the core router.

OSI focus: Layer 2 locality versus an accidental Layer-3 routed hairpin.

10. The corrected local test finally proved the AP path

For the corrected test:

wired test laptop
→ remote EX3300
→ U6 Ethernet
→ U6 5 GHz radio
→ Wi-Fi 6 test laptop

Both endpoints were on the same local VLAN/subnet.

No PowerBeam.

No core router.

No ISP.

The Wi-Fi 6 endpoint was associated at:

Wi-Fi 6
2x2 MIMO
1.20 Gbps RX PHY
1.20 Gbps TX PHY

Single-stream results

Wi-Fi → wired commonly ran in the 650–750 Mbps range, with a receiver summary around 672 Mbps.

Wired → Wi-Fi was commonly around 480–520 Mbps before one brief loss event. That event produced a large retransmission burst and pulled the final single-stream average down to roughly 481 Mbps.

The key point was already clear: the AP path was nowhere near a hard 200 Mbps ceiling.

Four-stream results

The final aggregate test used:

iperf3 -c "$SERVER" -P 4 -t 20 -O 3
iperf3 -c "$SERVER" -P 4 -R -t 20 -O 3

Completed summaries:

wired → Wi-Fi: 721 Mbps
Wi-Fi → wired: 722 Mbps

That was the decisive isolation test.

A 1.2 Gbps displayed PHY rate is not expected to become 1.2 Gbps of TCP payload. Real throughput is reduced by 802.11 protocol overhead, contention, acknowledgements, and other airtime costs.⁵

The local result cleared the tested path:

• U6 radio capacity under this load;
• U6 Gigabit Ethernet uplink;
• EX3300 local switching between the two test ports;
• the Wi-Fi 6 endpoint.

It did not prove that those components can never misbehave. It proved that the earlier ~200 Mbps end-to-end result was not an intrinsic throughput limit of this local AP path.

OSI focus: Layer 1 radio capacity validated with Layer-4 throughput after deliberately simplifying Layers 2 and 3.

11. What was proven, what was rejected, and what remained open

By the end of the session, the fault domain was much smaller.

Proven fault: the 100 Mbps passive-PoE injector

The original injector imposed a hard Fast Ethernet ceiling.

Replacing it allowed several hundred megabits per second.

Proven fault: the inline coupler panel

Repeated insertion reproduced:

• severe asymmetry;
• instability;
• eventual 100 Mbps renegotiation.

Repeated bypass restored:

• 1 Gbps negotiation;
• roughly 400/400 Mbps observed wired throughput across the PowerBeam path.

Cleared for the tested path: U6 and local switching

The corrected local test reached approximately 721/722 Mbps.

That substantially cleared:

• the U6 for this local throughput test;
• its Ethernet uplink;
• the EX3300 local switching path;
• the Wi-Fi 6 client.

Rejected: “Speedtest says 80 Mbps, therefore the bridge is an 80 Mbps bridge”

The same physical environment produced wildly different results depending on how the path was constructed.

Rejected: “The U6 is capped around 200 Mbps”

The local wired-to-Wi-Fi test exceeded 700 Mbps.

Still open: long-term remote-side copper stability

The coupler panel was strongly convicted, but a future 1 Gbps → 100 Mbps recurrence would still require a controlled swap order:

1. short EX3300-to-injector patch cable;
2. EX3300 port;
3. gigabit passive-PoE injector;
4. outdoor cable termination;
5. PowerBeam Ethernet PHY.

Still open: why the combined Wi-Fi-through-bridge path was lower

The isolated measurements were now roughly:

local U6 path:                ~720/720 Mbps
wired PowerBeam path:         ~400/400 Mbps when observed healthy
combined Wi-Fi + bridge path: often ~200–300 Mbps in earlier tests

Possible areas for the next phase included:

• PowerBeam channel width, signal, modulation/capacity, and retries;
• possible 5 GHz coexistence between local Wi-Fi and the bridge;
• traffic direction and retransmissions across the bridge;
• queueing or flow-control behavior at the Ethernet/radio boundary;
• accidental endpoint/VLAN path changes;
• transient link state that disappears when a cable is reseated.

One thing I deliberately did not conclude was that the U6 and PowerBeam were interfering.

That remained a hypothesis to measure.

12. The troubleshooting order that actually worked

The useful sequence was:

1. Remove hard physical ceilings. A 100 Mbps injector had to be fixed before higher-layer tuning meant anything.
2. Watch negotiated link state. A link that changes from 1 Gbps to 100 Mbps is evidence.
3. A/B test passive components. Repeated insertion and bypass turned suspicion into causation.
4. Measure both directions. Reverse iperf3 exposed the 430-versus-18 Mbps asymmetry.
5. Read TCP evidence, not just bitrate. Retransmissions and congestion-window collapse differentiated a broken path from a simple throughput ceiling.
6. Shorten the path. Local endpoints removed the bridge, router, and ISP from the AP test.
7. Verify VLAN and route locality. My wrong-subnet test crossed the bridge twice.
8. Compare single and parallel flows. A single TCP stream showed sensitivity to a transient event; parallel streams helped establish useful aggregate throughput.
9. Treat PHY rate as PHY rate. A 1.2 Gbps radio association is not 1.2 Gbps of application payload.
10. Keep hypotheses provisional. Several early explanations changed when the test path improved.

That is what “OSI-guided troubleshooting” meant in this incident.

It was not mechanically blaming Layer 1 first.

It was controlling the test so that lower layers were either supported by evidence or removed from the experiment before assigning blame higher in the stack.

13. Compact OSI map of the incident

14. Where the next session starts

The next troubleshooting session should not reopen already-cleared questions without new contradictory evidence.

The restart point is:

1. Keep the coupler panel out of the bridge path.
2. Verify the PowerBeam-facing EX3300 port is still 1 Gbps full duplex.
3. Capture PowerBeam frequency, channel width, per-chain signal, noise, modulation/capacity, retries, and Ethernet link state at both ends.
4. Run a fresh wired remote ↔ core iperf3 matrix in both directions.
5. Run the same matrix from the Wi-Fi 6 endpoint through the bridge.
6. Compare those runs while watching switch counters, bridge RF state, and Wi-Fi airtime at the same time.
7. Change one variable at a time.

At that point the remaining problem is narrow enough to measure instead of guess.

Part 2 will turn the commands used here into a compact OSI-layer runbook. Part 3 will preserve the evidence ledger: what each test proved, what it eliminated, what remained unresolved, and the exact restart state.

References