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

retronites · yesterday

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?

Townman · ‎22-08-2007

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

In another browser tab, login into the Plusnet user portal BEFORE clicking the fault & ticket links

Superusers are not staff, but they do have a direct line of communication into the business in order to raise issues, concerns and feedback from the community.

If this post helped, please click the Thumbs Up and if it fixed your issue, please click the This fixed my problem green button below.

retronites · yesterday

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"

corringham · ‎25-09-2015

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.

retronites · yesterday

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