The little SSH that sometimes couldn't (2012)
mina.naguib.ca
mina.naguib.ca
I've personally twice encountered similar issues, once with FTPS and another with HTTPS, both manifesting as strange cryptographic failures, but ultimately caused by broken network device somewhere in the path.
After some experimenting I determined that there was a particular 4 byte (if I remember the length correctly) string that simply could not be sent or received by my Ethernet card.
Some searching turned up something on some obscure support forum where the maker of that card admitted that there was a bug in the hardware's checksum implementation that made it fail on that byte pattern.
A friend of mine in college had an interesting hardware data corruption bug on a computer he built for his project in the microprocessor lab we both took in 1982. We did a joint project, where together we designed a small 68k based system and then separately each built a copy. Here's mine [1] [2].
On mine the serial ports worked fine up to 19200 bps (the limit of the ADM3a terminals we were using). On his once you got past 2400 bps it started getting errors.
That nature of the errors was such that only a subset of the possible ASCII characters could be sent. Characters outside that subset would be replaced by characters from the subset. The faster you went the smaller the working subset.
What happened was that there were filter capacitors on the serial lines to filter out high frequency noise. My filter capacitors were correct. His were not. When he had went to the EE stockroom to buy filter capacitor they gave him capacitors that were a couple of orders of magnitude bigger than he asked for.
On his system then if a character with too many bit transitions or bit transitions to close together those looked like high frequency noise to the filter capacitors and were filtered out.
The little ssh that sometimes couldn't (2012) - https://news.ycombinator.com/item?id=9865698 - July 2015 (8 comments)
The little ssh that (sometimes) couldn't - https://news.ycombinator.com/item?id=4709438 - Oct 2012 (63 comments)
Well, my first guess was they were going through a Xerox. :))
<http://www.dkriesel.com/en/blog/2013/0802_xerox-workcentres_...>
> A Montreal machine receiving this packet discarded it at the kernel level after realizing it’s corrupt, never passing it to the userland ssh daemon. London then re-transmitted it, going through the same corruption, getting the same silent treatment. From ssh and sshd’s perspective, the connection was at a stalemate. From tcpdump’s perspective, there was no loss, and Montreal machines appeared to be just ignoring data.
... it would have caught this! I suppose it's a good habit, because it's a cheap check for something that would be absolutely baffling otherwise.
https://unix.stackexchange.com/questions/750807/ssh-all-full...