Sustained uploads corrupted (TLS bad record mac) on AS7922 backbone path — all customer equipment eliminated, matches March report

Since at least late June 2026, every sustained upload from my line dies roughly 8 seconds in with a TLS integrity failure ("bad record mac") — payload bytes are altered in transit yet arrive with valid TCP checksums. Downloads and small requests are unaffected. Plan is residential 2 Gbps down / 200 Mbps up; effective upstream is ~30-40 Mbps until each stream is killed, and bulk uploads only complete via aggressive application-level retries.

Reproduction (fails within 1-3 attempts from any machine on the LAN): upload a 100 MB random file over HTTPS (e.g. curl -T to speed.cloudflare.com/__up) and the transfer terminates with "SSL alert bad record mac".

Customer-side equipment exhaustively eliminated:

- Two different physical machines reproduce identically

- NIC hardware offloads disabled (software-computed checksums) — still corrupts, implicating a TCP-rebuilding device beyond the demarc

- Router hardware flow acceleration disabled — still corrupts

- Router traffic shaping (SQM/CAKE) removed entirely — still corrupts

- LAN transfers are MAC-verified clean at 82-94 MB/s, so NICs/cabling/switching are fine

- Not TLS- or CDN-specific: scp over SSH (port 22) to a non-CDN host is killed mid-transfer the same way

- Clean 1500-byte MTU path

Traceroutes to both failing destinations (Cloudflare and OVH) share the same AS7922 backbone segment: 96.216.74.69 -> 96.110.5.141 -> 96.110.45.77. With everything on-premises ruled out, that shared segment is the corruption locus by elimination.

This matches the March 2026 report "Possible packet corruption affecting large TLS uploads on Comcast backbone (AS7922) toward Chicago CDN edges" in this same forum — same alert, same upload-only pattern, same customer-side elimination, and uploads via VPN tunnel unaffected. I have also posted my reproduction as a comment there. An Official Employee acknowledged that report in March; no resolution has been published.

I have a headers-only packet capture of a failing upload ending in the fatal alert, a timestamped test log, and full traceroutes available, and I am happy to send account details by direct message when requested. Could this be escalated to backbone/NOC engineering rather than premises troubleshooting? Local DOCSIS signals were normal in the matching March report, and two independent customers now show the same fingerprint.