Hacker News Reader

Comment by willis936 | Hacker News Reader

I don’t have numbers off hand, but from a feeling I have from memory, I would think it is extremely unlikely that TCP checksums are consistently failing to trigger retransmission. Someone must be altering packets along the way.

View on HN

TCP checksums are notoriously weak:

https://www.evanjones.ca/tcp-checksums.html

With enough packets passing the dodgy RAM a noticeable number will manage to get mangled in such a way that the checksum is still correct.

Checksums are also often recomputed on transit if the packet is intercepted, e.g. to limit TTL, unflag odd/unused TCP features, that kind of ISP-ish preening. So if it was a software error or even a hardware problem in the right (wrong) spot it’s possible to get this kind of corruption without retransmits.

I think you are confusing the IP header with TCP header.

Routers don’t touch the TCP header at all

if your router does NAT it touches the tcp header

You are right, although NAT could be classified as a firewall feature, that runs on routers.

But in any case it's irrelevant in this context as ATT shouldn't be doing any NAT

No. URG, “Christmas tree” packets, etc. all can be mangled by the ISP. Or more commonly dropped

In that case, won't there be significant packet loss causing throughput to be very slow? I don't know if this is possible without something messing with TCP headers.

It is triggering retransmission. It just retransmits until it gets lucky with the (pretty weak) TCP checksum.

Reply on news.ycombinator.com