Hacker News Reader

Comment by sidewndr46 | Hacker News Reader

Each TCP packet has a checksum but it does not catch 100% of all possible bit flips

And some routing hardware have been known to ignore this--meaning they'll forward the packet data along and re-calculate the checksum.

Hardware that forwards packets usually forwards IP packets, it doesn't care about TCP checksums and doesn't recalculate them. TCP stack in your OS is the one that does that.

It has to be a special kind of hardware that does much deeper packet inspection (DPI) to recalculate TCP checksums, usually used for spying, throttling, censorship, injecting ads, injecting exploits, etc., but not merely routing/forwarding packets.

Switches (L2 devices) recalculate Ethernet CRCs (L2 error detection codes), and routers tend to calculate TCP/UDP checksums (L3 error detection codes) and everything below. I've seen exactly this issue with switches that have bad RAM before, and I assume that they just have a router with bad RAM (and without ECC RAM, which looks embarrassing).

To my knowledge, from working on an actual software router, a router will only touch the TTL and recalculate the IP header checksum.

There is no reason for it to touch the TCP header.

Agreed there is no logical reason for it to touch the TCP header.

And yet, an unfortunate number of L2 switches do exactly that. :(

Doesn't NAT (specifically carrier-grade NAT in this case) often modify the port? Although I don't know if AT&T does carrier-grade NAT.

https://en.wikipedia.org/wiki/Carrier-grade_NAT

> an unfortunate number of L2 switches do exactly that

Can you name any? Just curious

Reply on news.ycombinator.com