Live data from Hacker News

The little ssh that (sometimes) couldn't

mina.naguib.ca

31–40 of 66 posts

Re: The little ssh that (sometimes) couldn't

#31

I love reading weird bug stories like this. Is there a place where lots of these types of stories are aggregated? Maybe a book about them?

Sorry, no links, typing quickly:

* F-Secure's blog and some other AV companies' blogs

* Ramond Chen's The Old New Thing

* Anything written by Mark Russinovich

* Slightly off topic, but http://www.devttys0.com/ manages some crazy reverse engineering feats, which I feel are similar to this story.

Re: The little ssh that (sometimes) couldn't

#32
A dev submitted code and broke our build once, when we looked at what he submitted there appear to random syntax errors in it. On his workstation the code was correct however.

We tracked it down to a switch that was corrupting packets enough that the TCP checksum wasn't sufficient protection, and the packets would simply pass their checksum despite having been altered.

The out come was that we always use compression, or encryption, as an added layer of protection.

Re: The little ssh that (sometimes) couldn't

#33

Off-topic: can someone provide a good reason why SSH w/ the HPN patches is not the default for every SSH install on every platform? Today, people are relying on SSH for binary transfer more than ever. SFTP and SCP are the new defacto file transfer standards between machine to machine over a secured connection. Source control like GIT (or even SVN) make heavy use of binary transfers over SSH. The performance benefit t…

I have to admit I felt pretty ignorant for not knowing what you were talking about. So, for anyone else in a similar situation: http://www.psc.edu/index.php/hpn-ssh

Re: The little ssh that (sometimes) couldn't

#34
Nice analysis.

I had a similar problem, less hairy, involving a bad bit in a disk drive's cache RAM. Took a day or so to figure out a solid repro.

Stuff like this does happen. Handling bit errors in consumer electronics storage systems is an interesting problem, and one that I'd love to see more attention paid to.

Re: The little ssh that (sometimes) couldn't

#35
post #17

Reminds me of a problem I had with a T1 circuit corrupting packets. Shortly after bringing up a second T1 into a remote location we discovered that some web pages would show broken JPG images at the remote site. Some troubleshooting revealed that this only happened when traffic was routed over the new T1. The old T1 worked just fine. Pings, and other IP traffic seemed to work over either line but we kept seeing the b…

One of my fellow ISP admins (silicon.net, I was elite.net) had the same problem around 1995. GIFs would load on web pages but not JPEGs. They'd load for some amount of time and then hang.

The way he diagnosed it was to do a transfer of /dev/zero out one link. It worked. But it stopped almost immediately out the problem link. It turned out to be the same problem -- no zero bit stuffing configured on the line.

By the way, this same technique, known as "weak bits", was used as a floppy and CD/DVD copy protection scheme.

Re: The little ssh that (sometimes) couldn't

#36
post #29

Reminded me of this: http://www.ibiblio.org/harris/500milemail.html

The numbers in this story do not add up. For a connection to be made within 3ms, there needs to be a round-trip within that time, which reduces the maximum possible radius by half.

Also, don't both photons in fiber and electrons in copper wire travel around 60% of the speed of light?

Re: The little ssh that (sometimes) couldn't

#37
post #17

Reminds me of a problem I had with a T1 circuit corrupting packets. Shortly after bringing up a second T1 into a remote location we discovered that some web pages would show broken JPG images at the remote site. Some troubleshooting revealed that this only happened when traffic was routed over the new T1. The old T1 worked just fine. Pings, and other IP traffic seemed to work over either line but we kept seeing the b…

Yes. I remember being so excited that the option for pinging with particular bit patterns finally came in handy when I was debugging a new T1.

Re: The little ssh that (sometimes) couldn't

#38
post #28
post #27

Can anybody think of an explanation why the 'bug' happened only after the 576th byte?

I loves me some speculation! Here goes: 576 decimal looks like this in other common bases: binary: 0000 00010 0100 0000 octal: 1100 hexadecimal: 240 My first inclination would be a firmware problem: was it upgraded recently? Are there any known problems with the version that was installed? Did you build it yourself? If we have access to the code, the information about the 'shape' of 576 may come in handy. Or maybe we…

576 bytes is the minimum datagram size that must be accepted by all nodes in an IPv4 internet.

In practice, on the modern Internet, you'll see tons of packets larger. So who knows; perhaps some massively outdated optimization in an ASIC somewhere resulted in different hardware paths for >576 bytes.

Re: The little ssh that (sometimes) couldn't

#39

Off-topic: can someone provide a good reason why SSH w/ the HPN patches is not the default for every SSH install on every platform? Today, people are relying on SSH for binary transfer more than ever. SFTP and SCP are the new defacto file transfer standards between machine to machine over a secured connection. Source control like GIT (or even SVN) make heavy use of binary transfers over SSH. The performance benefit t…

The none cipher switch was always a turn off for a lot of people.

Re: The little ssh that (sometimes) couldn't

#40
post #39

Off-topic: can someone provide a good reason why SSH w/ the HPN patches is not the default for every SSH install on every platform? Today, people are relying on SSH for binary transfer more than ever. SFTP and SCP are the new defacto file transfer standards between machine to machine over a secured connection. Source control like GIT (or even SVN) make heavy use of binary transfers over SSH. The performance benefit t…

The none cipher switch was always a turn off for a lot of people.

iirc, it's off by default?

Even when enabled, it'll only not encrypt binary blobs; TTY input will remain encrypted. Obviously many times that is not an option, but sometimes it is.

Post reply on HN