Possible packet corruption affecting large TLS uploads on Comcast backbone (AS7922) toward Chicago CDN edges

HIGH LEVEL SUMMARY

Large HTTPS uploads fail consistently with TLS error ERR_SSL_BAD_RECORD_MAC_ALERT when using a Comcast/Xfinity residential connection.

The identical uploads succeed immediately when routed through alternate backbone paths (Google Cloud WireGuard tunnel and corporate VPN).

Testing indicates the issue occurs specifically when traffic traverses Comcast backbone ASN AS7922 toward CDN edge infrastructure located in Chicago (ORD).

Uploads to services behind multiple CDN providers are affected, suggesting the issue may lie within Comcast backbone routing or peering rather than a single CDN provider.

ENVIRONMENT

ISP: Comcast / Xfinity
ISP ASN: AS7922

Gateway: Technicolor CGM4981COM (XB8)
Router: Linksys WRT3200ACM running OpenWRT
Client OS: Windows 11
Browser: Chrome

PROBLEM DESCRIPTION

Large HTTPS uploads fail with browser error:

ERR_SSL_BAD_RECORD_MAC_ALERT

This TLS alert indicates corrupted encrypted payload data was received by the server.

Failure characteristics:

• occurs during upload (usually early or mid-transfer)
• downloads and small requests succeed normally
• reproducible consistently on Comcast path
• disappears immediately when traffic is routed via VPN

NETWORK TESTING PERFORMED

MTU testing

ping -f -l 1472 files.bom.com → success
ping -f -l 1473 files.bom.com → fragmentation required

This confirms a standard 1500 byte MTU path.

Router testing

OpenWRT router flow offloading disabled.
No change in behavior.

NIC testing

All NIC hardware offload features disabled:

TCP checksum offload
LSO / TSO
GSO

No change in behavior.

TCP MSS testing

Router forced TCP MSS reduction (~1300 bytes).

Uploads still fail identically.

DOCSIS SIGNAL QUALITY

Comcast technician recently replaced drop cable and repaired damaged upstream line segment.

Current modem metrics:

Downstream SNR: ~45–46 dB
Downstream power: +6 to +8 dBmV
Upstream power: ~37–39 dBmV

These are well within normal operating ranges.

General traffic shows no packet loss or instability.

PRIMARY FAILURE CASE

Example failing service: BOM / Arena Solutions upload portal

Destination:
files.bom.com.cdn.cloudflare.net
104.18.2.221

Cloudflare ASN: AS13335

Example response header:

CF-RAY: 9d9b14808a06c93a-ORD

The "-ORD" suffix indicates traffic ingress through the Cloudflare Chicago POP.

Traceroute:

tracert -d files.bom.com

 1  <1 ms  <1 ms  <1 ms  10.95.29.1
 2   13 ms  12 ms   7 ms 100.92.46.2
 3   11 ms  13 ms  12 ms 69.139.243.81
 4   13 ms  12 ms  13 ms 96.110.94.18
 5    9 ms   8 ms   5 ms 162.151.127.97
 6   14 ms  15 ms  10 ms 96.108.20.93
 7     *    20 ms    *   96.110.42.181
 8   16 ms  25 ms  17 ms 96.110.33.214
 9     *      *      *   Request timed out
10   17 ms  18 ms  21 ms 141.101.73.218
11   21 ms  18 ms  20 ms 104.18.2.221

Earlier path inspection identified Comcast backbone routers including nodes at the Chicago internet exchange facility:

be-2211-pe11.350ecermak.il.ibone.comcast.net

Location:
350 E Cermak Rd
Chicago, IL

SECONDARY RELATED OBSERVATION

Intermittent upload failures also occur when uploading audio files to Audiomack.

Audiomack is hosted behind AWS CloudFront, not Cloudflare.

Example DNS resolution:

audiomack.com → 18.154.110.13 / 18.154.110.44 / 18.154.110.84 / 18.154.110.103

Example HTTP headers:

Server: CloudFront
X-Amz-Cf-Pop: ORD58-P6

This indicates the request is entering AWS CloudFront infrastructure at a Chicago ORD edge.

The presence of upload failures affecting services behind both Cloudflare and CloudFront suggests the issue may not be CDN-specific.

CONTROL PATH TESTING

Uploads succeed reliably when routed through alternate backbone paths.

Example: Google Cloud WireGuard tunnel

Traceroute via Google backbone:

 1  pi.hole [10.66.66.1]
 2  74.125.251.128
 3  141.101.73.4
 4  141.101.73.74
 5  104.18.2.221

Path summary:

Client
→ AS15169 (Google backbone)
→ CDN edge
→ destination

Uploads complete successfully via this route.

INTERPRETATION

TLS bad_record_mac alerts occur when encrypted TLS records fail integrity validation. This normally occurs only when encrypted payload data has been modified or corrupted in transit.

Given that:

• the problem occurs only on Comcast backbone path
• uploads succeed via alternate backbone paths
• MTU and MSS testing ruled out fragmentation issues
• local hardware and NIC offloading ruled out
• DOCSIS plant issues corrected and signal levels verified
• failures occur across multiple CDN providers entering Chicago edges

The most plausible cause is packet corruption or unusual handling of sustained upload flows somewhere along the Comcast backbone path entering Chicago CDN infrastructure.

Possible causes include:

• faulty backbone router line card
• failing optical interface
• forwarding ASIC issue
• peering interface hardware errors
• rare packet corruption in hardware forwarding path

REQUEST

Please investigate possible packet corruption or forwarding anomalies affecting traffic between Comcast backbone ASN AS7922 and CDN edge networks located in Chicago.

Because the issue affects multiple CDN providers (Cloudflare and AWS CloudFront), the problem may exist along a Comcast backbone segment or peering interface near the Chicago exchange facilities.

Details and sanitized pcap file available at https://gist.github.com/Efpophis/d81a07bde9e61323a8ecdfd221daf848