Thank you, saved me a click.

But this tells me the T1 was misconfigured with AMI signalling, which doesn't guarantee ones-density, and never should have been used for data in the first place. AMI is appropriate for voice, where the low bits of the PCM signal are always twiddling with noise, and statistically tend to provide plenty of transitions to keep the receiver clock synchronized.

The whole reason B8ZS was invented was to guarantee a sufficient number of transitions even in the presence of digital data, which often contains long runs of pure zero. By replacing an 8-zeroes-in-a-row string with an "invalid" pattern, the pattern still contains enough edges for the clock circuits, but the pattern is discarded as invalid and replaced with 8 zeroes again by the receiver.

B8ZS was considered mandatory on data circuits and we had special test patterns (really just a long run of zeroes with a 1 at the end) that would make AMI fail, in order to confirm that a whole path was properly configured with B8ZS.

The detail about POP3 and Excel attachment is extraneous and I can't see how it would matter. Nothing in the ones portion of the signal should throw of an already-framed circuit. Extraordinary claims and all that.

This won't work with the line coding of modern network protocols. The key part of this story is T1 using the older AMI coding that is susceptible to loss of sync from the right data pattern.

My last name contains the character sequence "rz".

Back in the BBS days this would trigger a Zmodem transfer on certain clients. It made a lot of people upset.

Some very poorly coded NAT boxes translated any bit pattern that looked like the local/public network IP address.

Did he play as a mage?

In a monkeys in front of a typewriter world, statistically, you are as likely to have a one off event that matches a specific bit pattern in the underlying format as you would the encrypted format. It would not be reproducible though since most encryption uses nonces

It's not particularly uncommon to have a non-cryptographic whitening/scrambling step as part of high-speed signalling protocols (e.g. PCI-E) in part for this reason. Even for interconnects between different chips on the same PCB.

For more context, read the comment[0] on Reddit's /r/sysadmin thread from the follow-up tweet[1]. It boils down to a certain bit-pattern in the spreadsheet's headers that corresponded to a signalling pattern in their T1 line, around the year 2003, causing the T1 equipment to fail.

[0] (2018) https://old.reddit.com/r/sysadmin/comments/9si6r9/postmortem...

[1] https://twitter.com/lauriewired/status/1838257118685921694

Repeated patterns in digital signals can cause errors in several ways such as DC bias (likely the case here), or a buildup of energy on the edges of the signal's fourier spectrum which then gets filtered out and shows up as signal degradation on the oscilloscope.

Nowadays the lower layer transmission protocols all re-code the signal to ensure frequent edge transitions, and after a few layers of that the odds of these patterns causing problems goes way down.

And then compression and encryption (hopefully in that order!) make it go away entirely.

Buuut, 25 years ago network equipment wasn't as layered and sophisticated as it is today, so that sort of thing would crop up now and then.

Oh, it's entirely possible in principle (I don't know about the details of T1 in this specific case).

Many years ago, there used to be a vulnerability with a lot of modems where you could send a ping packet to a machine connected via dialup, and the machine would send back a response that its modem would interpret as telling it to hang up the call: https://seclists.org/bugtraq/1998/Sep/192

The OSI model is an abstraction that can be broken by implementation bugs or design flaws, not an immutable law of the universe.

EDIT: I see that some of the Twitter replies beat me to mentioning this.

OSI model makes it more possible. After all for each layer anything above it is just well bits... And if some layer is poorly implemented it can interpret certain run of bits as something else and act accordingly, but wrong.

There is lot of bad code specially when you have multiple implementations and all doing their own thing on their own level.

> JSDevOps says lower level bitstream-induced error is "fucking bollocks".

Surely, JSDevOps knows what he is talking about. I will rest peacefully with this in mind.