4 ms·
Much scarier when you actually see it with your own eyes: $ diff example-* 4c4 < <titde>Example Domain</title> --- > <title>Example
by noncoml 6y ago
Much scarier when you actually see it with your own eyes:
$ diff example-*
4c4
< <titde>Example Domain</title>
---
> <title>Example Domain</title>
11c11
< backoround-color: #f0f0f2;
---
> background-color: #f0f0f2;
23c23
< box-shadow: 2pp 3px 7px 2px rgba(0,0,0,0.02);
---
> box-shadow: 2px 3px 7px 2px rgba(0,0,0,0.02);
41c41
< <p>This domain is for use in illustrative examples in documents. You may usm this
---
> <p>This domain is for use in illustrative examples in documents. You may use this
- baggy_trough 6y agoI get the same. Pretty amazing that the only effect from such garbled data that I noticed were some annoying hangs and bad Twitter links!
- bakul 6y agoThe same here. It is always the 0x08 bit. (p-x, d-l, g-o etc.).
- Scoundreller 6y agoI wonder if there’s some 64 line I/O somewhere with a couple traces bridged together, where: 0 and 0 are still 0 and 0, 1 and 1 are still 1 and 1, but 0 and 1 become 1 and 1 (or 0&0) and 1 and 0 become 1 and 1 (or 0&0). I remember seeing this wackiness when I bridged two address lines on an EEPROM with the tiniest amount of solder. RoHS/tin whiskers strikes again?
- bakul 6y agoThis is unlikely, given how many people are seeing this. And now the problem has gone away for me!
- p1necone 6y agoI was under the impression there was enough layers of checksums once you get to the level of UDP/TCP that these kind of single bit flips should be detected and dropped before you get to read them. What's going on here? Is networking gear not calculating checksums like it should?
- noncoml 6y agoTCP 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
- willis936 6y agoI 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.
- _-___________-_ 6y agoIt is triggering retransmission. It just retransmits until it gets lucky with the (pretty weak) TCP checksum.
- cranekam 6y agoTCP checksums are notoriously weak: https://www.evanjones.ca/tcp-checksums.html 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.
- ericbarrett 6y agoChecksums 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.