3 ms·

The checksum should be checked by your computer. So somehow the packet is being repackaged with the correct checksum, but for the wrong data. In other words, wh

The checksum should be checked by your computer. So somehow the packet is being repackaged with the correct checksum, but for the wrong data. In other words, when your computer checks the checksum, it matches. Another possibility is that somehow only errors that result in the same checksum are being generated.

toast0 6y ago
Or their computer isn't checking the checksum. As is apparently the case on mac os (as reported elsewhere in the thread). Another quality product by Apple ;P
- holycrapwhodat 6y ago
  Except it was trivial to reproduce with the script on non-Apple devices, and people in one of the many Twitter threads surrounding this showed that on their Mac there was MANY tcp retransmits due to invalid checksums, and the bit-flipped packet did have the correct checksum. https://twitter.com/KielO/status/1335640544496689152 https://twitter.com/KielO/status/1335640544496689152
  - toast0 6y ago
    OK, that tweet does show the checksum is OK. I didn't see a whole lot of tcpdumps, so had to go with what was reported in the thread (I tried to reproduce with a few people, but my server wasn't in the broken path, so I couldn't get a lot of real data). That tweet in particular doesn't show any retransmits. tcpdump/wireshark gets a little hard to read at times; especially when the packet dump is a lie: all those packets marked red for bad checksums are from the dumping machine, and the checksums are wrong because the NIC is filling them in, and the capture interface doesn't get to see what they are). Perhaps the other people in the thread who said mac os was ignoring bad checksums were also confused; or perhaps it does ignore bad checksums, it's pretty bad at networking (it can't handle a synflood in 2020 because it's got synhandling code from 2000)
- cranekam 6y ago
  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)

toast0 6y ago

Or their computer isn't checking the checksum. As is apparently the case on mac os (as reported elsewhere in the thread). Another quality product by Apple ;P

holycrapwhodat 6y ago
Except it was trivial to reproduce with the script on non-Apple devices, and people in one of the many Twitter threads surrounding this showed that on their Mac there was MANY tcp retransmits due to invalid checksums, and the bit-flipped packet did have the correct checksum. https://twitter.com/KielO/status/1335640544496689152 https://twitter.com/KielO/status/1335640544496689152
- toast0 6y ago
  OK, that tweet does show the checksum is OK. I didn't see a whole lot of tcpdumps, so had to go with what was reported in the thread (I tried to reproduce with a few people, but my server wasn't in the broken path, so I couldn't get a lot of real data). That tweet in particular doesn't show any retransmits. tcpdump/wireshark gets a little hard to read at times; especially when the packet dump is a lie: all those packets marked red for bad checksums are from the dumping machine, and the checksums are wrong because the NIC is filling them in, and the capture interface doesn't get to see what they are). Perhaps the other people in the thread who said mac os was ignoring bad checksums were also confused; or perhaps it does ignore bad checksums, it's pretty bad at networking (it can't handle a synflood in 2020 because it's got synhandling code from 2000)
cranekam 6y ago
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)