Re:AT&T Fiber in the SF Bay Area is flipping bits
by cranekam on Tuesday December 08, 2020 @01:48AM
(#25342607)
There’s no proof of this. And what possible reason would macOS have for not checking the checksum? Although the checksum is weak it presumably catches at least some corrupt traffic. Do you really think Apple would just skip the TCP checksum and make its network performance less reliable when they have already implemented (or maintained if it came from BSD) the rest of a TCP/IP stack, which is vastly more complex, just because its developers are lazy?
[ Parent
| on HN ]
Re:AT&T Fiber in the SF Bay Area is flipping bits
by toast0 on Tuesday December 08, 2020 @03:34AM
(#25343166)
There were reports in the twitter threads that macs were ignoring the bad checksum (and I thought I saw confirmations in this thread, blaming a driver). Since I don't have a mac anymore, I couldn't confirm or deny; and since I don't have any equipment with the bad equipment in the path, I couldn't get a tcpdump, and I hadn't seen any on twitter.
I wouldn't have expected Apple to purposefully break the checksum, just like they I don't think they purposefully have no synflood protection because they pulled the TCP/IP stack at the turn of the century and never pulled it to get the many many many upgrades from upstream (although, they did add on MP-TCP, so there's that). I wouldn't be surprised if tcp checksums had stopped working ages ago, possibly because of a aggressive driver, and nobody noticed. Kind of like how if you spawn a few thousand threads that just sit around sleeping, it will delay watchdog kicks and the kernel will panic. (also, from reports on here, not personal experience)
Re:AT&T Fiber in the SF Bay Area is flipping bits
by cranekam on Tuesday December 08, 2020 @02:37AM
(#25342869)
It also seems quite easy to verify this hypothesis with scapy:
>>> p1 = IP(dst="192.168.mac.ip")/TCP(dport=1984,sport=20001)
>>> p2 = IP(dst="192.168.mac.ip")/TCP(dport=1984,sport=20002)
>>> p2.show2()
###[ IP ]###
version = 4
ihl = 5
tos = 0x0
len = 40
id = 1
flags =
frag = 0
ttl = 64
proto = tcp
chksum = 0xf905
src = 192.168.linux.ip
dst = 192.168.mac.ip
\options \
###[ TCP ]###
sport = commtact_http
dport = bb
seq = 0
ack = 0
dataofs = 5
reserved = 0
flags = S
window = 8192
chksum = 0xb836
urgptr = 0
options = []
>>> p2[TCP].chksum = 0xb836 ^ 0x8 # mangled checksum
>>> sr1(p1, timeout=1)
Begin emission:
Finished sending 1 packets.
....*
Received 5 packets, got 1 answers, remaining 0 packets
<IP version=4 ihl=5 tos=0x0 len=44 id=0 flags=DF frag=0 ttl=64 proto=tcp chksum=0xb902 src=192.168.mac.ip dst=192.168.linux.ip |<TCP sport=bb dport=microsan seq=1671494800 ack=1 dataofs=6 reserved=0 flags=SA window=65535 chksum=0x6039 urgptr=0 options=[('MSS', 1460)] |>>
>>> sr1(p2, timeout=1)
Begin emission:
Finished sending 1 packets.
.....................................................................................................................................................................................
.....................................................................................................................................................................................
....................................................................................................................................
Received 494 packets, got 0 answers, remaining 1 packets
My Mac silently dropped the packet with the mangled checksum.