topic Re: FTTP Upstream Packet/Data Corruption on HTTP POST Requests (Not MTU) in Full Fibre

FTTP Upstream Packet/Data Corruption on HTTP POST Requests (Not MTU)

retronites — Tue, 23 Jun 2026 19:32:24 GMT

I am experiencing severe upstream data corruption specifically on outbound HTTP POST requests to various APIs and developer tools (including Anthropic API, Postman, and httpbin). The packets are arriving corrupted or truncated at the destination servers.

I have fully isolated the issue on my end:

Tested with both the stock Plusnet Hub Two and a separate third-party router
Tested across multiple client devices over Ethernet as well as Wi-Fi
Everything works fine on mobile hotspot
MTU settings thoroughly tested and ruled out

Because this is FTTP, the issue is not copper line noise. A frontline phone agent told me Plusnet "can't resolve upstream issues," which seems unacceptable for a Full Fibre connection. I believe this requires escalation to Tier 2 / Network Operations to check for:

An Openreach ONT hardware buffer defect or optical attenuation fault.
A provisioning/routing error on my specific Plusnet central gateway or local exchange VLAN.

Any other suggestions?

Re: FTTP Upstream Packet/Data Corruption on HTTP POST Requests (Not MTU)

Townman — Tue, 23 Jun 2026 19:50:24 GMT

Do you always get the same failure for the same “input”.

Re: FTTP Upstream Packet/Data Corruption on HTTP POST Requests (Not MTU)

retronites — Tue, 23 Jun 2026 19:57:36 GMT

No - and I suspect this is due to which packets might be getting dropped when. I have been running a script doing curl POSTs with a 60KB payload and it fails ~93% of the time, and always 100% ok on a mobile hotspot.

Errors are either "SEC_E_MESSAGE_ALTERED (0x8009030F) - The message or signature supplied for verification has been altered" - TLS CRC failure essentially, or "CURLE_RECV_ERROR" - connection loss (probably due to garbage packets establishing connection). I occasionally get an actual 200 response.

As far as I can tell downloads and smaller uploads work ok.

In a Linux environment the SEC_E error instead comes back as an SSL error "bad record mac"

Re: FTTP Upstream Packet/Data Corruption on HTTP POST Requests (Not MTU)

corringham — Tue, 23 Jun 2026 20:10:15 GMT

Check your system's time is correct - one cause of that error is a time difference between source and destination which invalidates the encryption used. It isn't the only cause, but is probably the easiest to fix.

Re: FTTP Upstream Packet/Data Corruption on HTTP POST Requests (Not MTU)

retronites — Tue, 23 Jun 2026 20:15:10 GMT

Noted - though this is happening on multiple separate devices, I have done a lot of frustrating device-side debugging today

Re: FTTP Upstream Packet/Data Corruption on HTTP POST Requests (Not MTU)

retronites — Wed, 24 Jun 2026 19:10:55 GMT

Update: I've measured both directions over 20+ hours on the same line:

Outbound (repeated 60KB HTTPS uploads, every 3 min, to two unrelated endpoints): ~5% failure overnight, rising to 80–97% failure from ~13:00 through 19:00. All failures are connection resets mid-upload. Identical rate to both destinations, so it's not a server-side or application issue.
Inbound (ThinkBroadband BQM, continuous): 0.12% loss, flat 8ms latency all day therefore the downstream path is healthy.

This pattern: clean inbound, outbound collapsing specifically under daytime/evening load still looks to me like upstream contention/capacity on my aggregation node or the BRAS, not a physical line fault (which is why an automated line test shows nothing).

Graph of the results over time attached.