← Back to Blog
homelabnetzwerkunifidebuggingJuly 7, 2026 · 7 min read
StandardSimply explained

When your 600 Mbit fiber line feels like 300: a detective story with the UniFi UCG Ultra

ONT · PPPoE direct test · DPI · 300 → 600 Mbit
Editorial diagram: a UCG router panel with the Critical Apps rule highlighted, behind it a DPI funnel choking the data stream; on the left an ONT and a laptop running the PPPoE direct test at the full 600 Mbit, on the right two gauges reading 300 and 600 Mbit.Editorial diagram: a UCG router panel with the Critical Apps rule highlighted, behind it a DPI funnel choking the data stream; on the left an ONT and a laptop running the PPPoE direct test at the full 600 Mbit, on the right two gauges reading 300 and 600 Mbit.

Four hours, a PPPoE stack on the Linux laptop, an unplugged switch, a disabled honeypot, a deleted content filter — and in the end it was a single QoS rule. This is the story of a performance-debugging session that showed me how treacherous harmless-looking features on a consumer gateway can be. And along the way, a guide to testing a fiber line directly under Linux, without your own router in between.

The setup

  • Line: O2 Home XL 600 Flex (600/300 Mbit) over Telekom FTTH infrastructure
  • ONT: Huawei EcoLife (bridge mode, 1 GbE)
  • Router: UniFi Cloud Gateway Ultra (UCG Ultra)
  • Symptom: speed tests consistently show ~300 Mbit download instead of the expected 600

Half. Exactly half. That’s a pattern that makes any network person pause: a duplex mismatch looks exactly like this. But we didn’t have one.

What we tried and ruled out

Before I get to the resolution, here’s the list of suspects we cleared one by one.

Layer 1 (cables and ports): Every Ethernet cable was Cat6, all links negotiated 1 GbE full duplex, the 2.5G switch between workstation and UCG was removed entirely: no change. The workstation’s NIC (Intel I225) held 2.5 Gbps full duplex, stable.

ISP profile: First a speed test against a Czech server (435 Mbit), then against a server practically around the corner: suddenly 598 Mbit. Important lesson: always test against several speed-test servers before you swap hardware. A single badly connected server distorts the picture completely.

ONT: The suspicion that the Huawei EcoLife was the limit could be cleared by plugging the laptop straight into the ONT and dialing in via PPPoE (guide below). Full 600 Mbit. It wasn’t the ONT.

UniFi security features: Honeypot disabled (brought a small jump), IDS/IPS was already off, a content filter didn’t even exist as a policy, threat management off.

Hardware offloading: Active by default on the UCG Ultra and not switchable.

VPN configuration: A policy-based-routing rule for Proton VPN was configured but disabled, the tunnel “Not Established”. Removed entirely as a test: no change.

Firewall rules: 151 firewall rules, 87 default policies, 4 VLANs, 2 WireGuard servers. Complex, but not the problem.

The Linux direct test: PPPoE on the laptop, no router

This was the decisive diagnostic step: take your own router out of the picture entirely and prove the line itself is fine. Linux can do this with on-board tools, but there are a few traps.

Prerequisites

# On Arch / CachyOS
sudo pacman -S rp-pppoe ppp

Create the VLAN interface

O2 on Telekom FTTH runs over VLAN 7. It has to be tagged on the Ethernet interface:

# Create VLAN 7 on the physical interface
sudo ip link add link enp0s31f6 name enp0s31f6.7 type vlan id 7
sudo ip link set enp0s31f6 up
sudo ip link set enp0s31f6.7 up

Adjust the interface name to your hardware (ip link show lists them all).

PPPoE configuration

File /etc/ppp/peers/o2:

plugin /usr/lib/rp-pppoe/rp-pppoe.so
nic-enp0s31f6.7
user "[email protected]"
defaultroute
usepeerdns
persist
noauth
mtu 1492
mru 1492

Important: nic-<interface> as its own line directly after the plugin. Otherwise pppd doesn’t know which interface to start PPPoE discovery on.

File /etc/ppp/chap-secrets:

[email protected]  *  YOUR_PASSWORD  *

The credentials are in the O2 customer portal under “Mein Vertrag → Zugangsdaten”.

Quieting NetworkManager

A common trap: NetworkManager tries DHCP on the interface in parallel while pppd is building the PPPoE session. That interferes.

sudo nmcli device set enp0s31f6 managed no
sudo nmcli device set enp0s31f6.7 managed no

Important: the old PPPoE session has to die first

This was the moment I was close to giving up. Symptom: Timeout waiting for PADO packets. Translation: the laptop sends PPPoE discovery packets (PADI), but nobody answers (PADO).

The reason: on O2’s side, the router’s PPPoE session is still running. The BNG (Broadband Network Gateway) allows only one session per line. As long as the old one is active, new PADIs are ignored.

The procedure:

  1. Cut power to the UCG Ultra, don’t just pull the network cable
  2. Cut power to the Huawei ONT too, wait 30 seconds
  3. Power the ONT back on, wait until the PON LED is solid green
  4. Wait 5–10 minutes so the old session times out at the OLT
  5. Only then start pppd

Connecting

sudo pppd call o2 nodetach debug

nodetach debug shows what’s happening right in the terminal. No back and forth between terminals and journalctl.

If everything works, a ppp0 interface appears, a public IP is assigned, and the laptop has direct internet access at the ONT, bypassing your own router.

# Speed test with the official Ookla client (not the Python speedtest-cli, which underperforms)
speedtest -s 23712

In my case: 598 Mbit down, 293 Mbit up. Line diagnosis complete, the provider delivers what it should.

Back to normal operation

sudo killall pppd
sudo ip link delete enp0s31f6.7
sudo nmcli device set enp0s31f6 managed yes
sudo nmcli device disconnect enp0s31f6
sudo nmcli device connect enp0s31f6

The resolution: it was the Critical Apps

After all the obvious suspects were cleared, the culprit sat inconspicuously at the top of the UniFi policy engine: a QoS rule named “Critical Apps Prioritization” with the action “Prioritize” and a list of applications — Microsoft Teams, Zoom, plus three more.

The rule had been created at some innocent point, “because it can’t hurt”. It looked harmless: only prioritizes a few apps, blocks nothing.

What it actually does: application-based QoS on the UCG Ultra means deep packet inspection. On every single packet. For the router to know whether a packet belongs to Teams or not, it has to analyze it: headers, payload patterns, sometimes SNI inspection on encrypted connections.

According to the data sheet, the UCG Ultra has a quad-core ARM Cortex-A53 at 1.2 GHz. That’s not much CPU for DPI at 600+ Mbit. Under normal load it’s enough, but as soon as a single stream wants to fill the whole line, the CPU budget runs out. The result: almost exactly half the profile gets through.

Rule disabled. Speed test:

Download: 647.75 Mbps
Upload:   304.01 Mbps
Packet Loss: 0.0%

Even slightly above the profile. Mystery solved.

Lessons learned

1. Application-based QoS is a performance killer on consumer hardware. If you really want to prioritize Teams or Zoom, it works without DPI: DSCP marking on the client (Windows group policy or registry). Then the router recognizes the priority from a single byte in the IP header, no payload scan needed.

2. The UCG’s internal speed test ≠ forwarding performance. The built-in speed test runs on the device itself and doesn’t pass through the firewall and QoS pipeline. 580 Mbit internally doesn’t mean clients reach the same speed.

3. “Exactly half” throughput doesn’t have to be a duplex mismatch. It can also be CPU saturation from DPI. The symptom is the same.

4. The speed-test server counts too. The first test against a badly connected server almost sent me in completely the wrong direction. Always try two or three different servers, ideally one directly inside the ISP’s network.

5. Single-stream vs. multi-stream. Browser speed tests open several parallel connections. curl with a single download often shows dramatically different numbers. Both are valid, but they measure different things. On my fully configured UCG: speed test 380 Mbit, single-stream curl only 160 Mbit. After the fix: both around 600.

6. The Linux PPPoE direct test is worth gold. As soon as you suspect a router configuration issue, the most important question is: is it the line, or is it my hardware? With the laptop straight on the ONT you settle that in ten minutes.

What I’d do differently next time

For UniFi performance problems, the order of interrogation is roughly this:

  1. Application-based QoS (check the top of the policy engine)
  2. Honeypot, threat management, content filter — everything that inspects packets
  3. Smart Queues on the WAN interface
  4. Region blocking, encrypted DNS filtering
  5. Firewall rule complexity with GeoIP or application match
  6. Only then suspect the hardware

Always use the Linux direct test as the first step to validate the line before you spend hours poking at the router configuration.