3 ms·

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

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?

cranekam 6y ago
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.
toast0 6y ago
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)
ncmncm 6y ago
It is extremely common for hardware to be configured to ignore checksums. ("A packet with a bad checksum would have been dropped before it got here. Our cabling is too short to drop bits.")

cranekam 6y ago

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.

toast0 6y ago

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)

ncmncm 6y ago

It is extremely common for hardware to be configured to ignore checksums. ("A packet with a bad checksum would have been dropped before it got here. Our cabling is too short to drop bits.")