TP-Link EAP770 Bug: ⚠️ Corrupted Wi‑Fi Downloads Fix

The symptoms did not point to the access point

I bought a TP-Link EAP770 in August 2023. It's a Wi‑Fi 7 access point built around a Qualcomm IPQ9574, running Linux 5.4.164 and firmware from June 2023. At first, the connection felt only a bit unreliable: a video might buffer now and then, but most of my work lived on a wired workstation.

The real problem showed up when I used rsync to copy my home directory to a laptop over Wi‑Fi. Transfers involving files larger than a few gigabytes would fail with SSH message authentication code errors. Because SSH and rsync sit at the visible end of the transfer, I spent time adjusting SSH options and adding retry logic. Some changes made failures more or less frequent, which made it look like application-level weirdness.

A few pieces of evidence argued against a network fault. Wireshark didn't show bad checksums or retransmissions, and a single UDP stream carrying random data arrived intact. I trusted TCP - at least that trust was reasonable in general. But TCP can only verify what it's told it received, and a checksum that gets recalculated after corruption can still come out "valid."

Later, I routed my home-network traffic through Tailscale. Its WireGuard tunnel authenticates packets and drops anything that fails authentication. Inside the tunnel, TCP saw missing packets and retransmitted. The failures stopped needing retries, which looked like a fix. In reality, it was a change in how the corruption got detected and handled - so I stopped investigating too early.

Support status didn't help, either. In 2025, I noticed other networking gear was getting firmware updates while the EAP770 stayed on the same original build. TP-Link support initially couldn't find the EAP770 v1 in its database. After I sent photos of the unit and packaging, TP-Link confirmed the EAP770 v1 was end-of-life and would receive no further firmware updates.

There was also a "buy before it's fully settled" gamble. I bought the access point before Wi‑Fi 7 was finalized and before it had Wi‑Fi Alliance certification. That doesn't prove the corruption came from the early standardization period - but it's a useful reminder: "Wi‑Fi 7" on the box isn't the same thing as certification, stable firmware, and a credible update path.

Packet captures exposed where corruption happened

Switching to NixOS made the problem harder to ignore. A 128 MiB download from a binary cache failed over HTTP/2 but succeeded over HTTP/1.1. Git clones also failed, and HTTPS connections sometimes ended with a TLS "bad record MAC" error. In March 2026, a multi-gigabyte NixOS ISO download stopped with a TLS record-layer error after transferring more than 2.7 GB.

Forcing HTTP/1.1 wasn't an explanation, just a workaround. My guess is that the faster HTTP/2 transfer made the problem easier to trigger, but I couldn't prove that. Protocol differences change timing and concurrency, so a successful transfer under one protocol doesn't automatically identify the faulty component.

I captured a failing HTTPS transfer with tcpdump. One 1,440-byte TCP segment contained 64 consecutive incorrect bytes, yet its TCP checksum was valid. The kernel's TcpInCsumErrors counter stayed at zero. TCP accepted the segment and handed the payload to TLS, and TLS rejected it because the record's authentication check no longer matched.

That observation redirected the investigation. A valid checksum on damaged data suggested that something modified the payload and then recalculated the checksum - or that the reported checksum status didn't describe the final bytes actually delivered upward.

To compare the real data, I ran a raw TCP test between a wired machine and the Wi‑Fi laptop, bypassing encrypted HTTPS. The raw test showed corruption only when multiple TCP streams ran at the same time, and only in the LAN-to-Wi‑Fi direction. Over 8,192 MiB, it found three damaged 64-byte blocks, each starting with zeros.

Direction and location narrowed things quickly. Wired clients were clean. The laptop's Wi‑Fi adapter had been swapped, but the failures persisted. Since the wireless frames' CCMP integrity checks were intact, corruption over the air looked less likely. That left the access point's bridging between its Ethernet and Wi‑Fi sides.

Even the 64-byte block size mattered. It matched a cache line on the IPQ9574 CPU cores. Qualcomm's SFE/PPE offload is the component that accelerates bridged traffic and handles packet checksums. At that point, a cache/DMA interaction became a stronger hypothesis than random radio interference. It stayed a hypothesis until the behavior changed when the offload was disabled.

The workaround was simple; access was not

Reading the available driver source pointed to turning off two SFE settings:

echo 0 > /sys/sfe/l2_feature
echo 0 > /sys/sfe/ppe_rfs_feature

Those files were writable only by root. The SSH account TP-Link provided ran as a low-privilege user with no capabilities, and the management interface didn't offer an equivalent toggle. There also wasn't a supported v1 firmware image to patch and install. Firmware for a related v2 or EAP773 model wasn't a safe substitute, and attempts to install a sibling model's image were rejected.

On top of that, the access point's shell was more restricted than a quick command-line workaround would require. I couldn't find a workable route through the device's own binaries or its management interface. At that point the realistic options were: replace the device, attach directly to its flash storage, or find a way to change the runtime setting while keeping it running. Replacing the device just because the vendor had stopped supporting it was an expensive answer to something that really came down to two writes.

So I looked at the kernel. The original write-up describes using the publicly documented Linux vulnerability CVE-2022-0185 and existing research into pipe-buffer manipulation to get the access needed to make the change. The exact exploit is a one-shot operation per boot: the device needed to stay running, and a failed attempt could panic it. This article doesn't reproduce an exploit chain or give instructions for gaining access to devices. The point is more mundane and more frustrating: a security vulnerability became the only practical path to apply a benign configuration change on hardware I already owned.

Once I disabled the offload, the corruption stopped repeating in raw TCP tests. An overnight LAN-to-Wi‑Fi transfer completed with zero damaged blocks. In the same setup, throughput dropped from 103.4 MiB/s with offload enabled to 95.4 MiB/s with it disabled - about an 8% reduction. Uploads from Wi‑Fi to the LAN were already clean, which matched the direction-specific behavior seen during diagnosis.

These results strongly implicated the offload path as the trigger, but they also don't mean every EAP770 behaves identically or that this is a vendor-approved fix. The settings reset after reboot. In this case, a separate monitoring process reapplied them after the device restarted. That's fragile maintenance, not a real alternative to a firmware update.

If you're troubleshooting similar equipment, don't run an exploit on a production network device. Isolate the device, contact the vendor, or replace it if you can't apply a supported fix safely.

What this incident says about networking and support

The underlying issue appears to involve packet-buffer recycling and DMA cache maintenance in Qualcomm's out-of-tree network driver. In broad terms, a transmit path can hand a buffer back for reuse, while a receive path later gives that same buffer to the network interface controller. On this ARM system, DMA writes to memory don't automatically keep CPU caches coherent. The driver has to manage the relevant cache lines correctly.

The source analysis suggests a buffer flagged as fast-recycled could skip an invalidation step on receive. If an old dirty cache line stayed around, it could later be written back over data that the network interface had just placed in memory. Because cache lines are 64 bytes, the damage size matched what was observed. The hardware and driver then reported checksum information that didn't reveal the corruption at the point where it actually happened.

This isn't the same as a simple flipped bit on the wireless link. The packet could pass the radio's integrity check, get altered inside the access point, and then still show a valid TCP checksum over the altered contents. TLS and SSH did their job: they detected that the authenticated record didn't match what was received. The visible errors showed up at the application-security layer, but the real cause sat lower down in the forwarding path.

The performance trade-off is real. Fast-path offload exists to move traffic efficiently, and disabling it reduced throughput in the test. But throughput doesn't help if the data you're moving is wrong. For downloads, builds, backups, and software updates, integrity comes before a small speed bump. The long-term fix should be a corrected driver or firmware release - not asking users to accept corrupted transfers or keep a workaround alive indefinitely.

This case also highlights something that often gets ignored: product support is part of the technical design. A network appliance isn't "done" when it leaves the factory. Firmware updates, security fixes, documentation, and upgrade paths determine whether owners can respond when a defect shows up. If a product is technically capable but unsupported, even a small configuration hole can turn into a hardware replacement decision - or, in this case, a level of reverse engineering that shouldn't be necessary.

There's a separate Wi‑Fi issue mentioned in the same source account that shouldn't be conflated with the packet corruption. The laptop's Qualcomm WCN785x adapter periodically stopped transmitting for one to four minutes. Access-point logs didn't show corresponding receive errors, while the laptop's driver queue grew and later drained in bursts. That evidence pointed toward the adapter's closed firmware, but didn't prove the exact cause. The write-up also mentions testing whether the behavior changed when the access point's 5 GHz radio switched from Wi‑Fi 7 to Wi‑Fi 6.

A useful troubleshooting sequence for similar failures is:

• Separate symptoms by direction. Test LAN-to-Wi‑Fi, Wi‑Fi-to-LAN, and wired-to-wired traffic independently.
• Compare layers. Application errors, TCP counters, packet captures, and link-layer checks answer different questions.
• Use known data. A raw transfer between controlled endpoints can reveal corruption that encryption otherwise hides.
• Change one variable at a time. Protocol, adapter, offload, and radio-mode changes can alter timing without identifying the root cause.
• Treat a workaround as temporary. Track its performance cost, persistence behavior, and risks - then push for a supported fix or replacement.

The original investigation and later updates are documented in the source write-up. The main lesson isn't "every bad download needs kernel debugging." It's that a valid checksum only proves something about the bytes at a specific point in the path. When security layers report corruption but transport counters look clean, it's worth questioning the network hardware and offload path, not just the app.