Hacker News Reader

HNHacker News

Top New Best Ask Show Jobs

Comment by noncoml | Hacker News Reader

Parent Full thread

noncoml·

TCP header does have a checksum that is supposed to check both the header and the payload.

So either the bit corruption is such that is not detected by the checksum

Or ATT is doing something nefarious and touches layer 4 and corrupts the data while doing so

View on HN

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.

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

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.

Reply on news.ycombinator.com