Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The little ssh that (sometimes) couldn't

mina.naguib.ca

Post reply on HN
Print view View original

61–66 of 66 posts

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

#61

Post by rlpb »

mikeash wrote: post #23

Well, while we're at it, here's my crazy MTU-related war story, although not as crazy as that one! I was troubleshooting with a user of an audio streaming application running over a LAN. The user could stream classical music but not rock music. Seriously. Classical was fine, but when streaming rock, the connection would drop after a few minutes. The application took chunks of audio, compressed them with a lossless co…

Having a smaller MTU is fine. The problem comes when people start blocking the ICMP fragmentation needed packets, presumably due to some assumption that this will in some way help with security.

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

#62

Post by bowmessage »

ChuckMcM wrote: post #8

That is an awesome story. If you're in devops I would suggest you look at the sequence of events, especially the debugging decision tree. You can't always get access to all of the machines but you can create 'views' by going through them. Sort of like astronomers using a gravitational lens. We had a similar issue at Blekko where a 10G switch we were using would not pass a certain bit pattern in a UDP packet fragment.…

Sounds more like a workaround, less of a fix :P. Weird stuff!

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

#63

Post by nsheridan »

ComputerGuru wrote: post #26

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…

It's pretty much unmaintained.

Every host it's installed on has to be properly tuned. Fine for large setups where finely tuned TCP stacks are the norm and maintaining your own ssh isn't much overhead, probably not fine for most setups where the 2MB buffer does the job. "To compute the BDP, we need to know the speed of the slowest link in the path and the Round Trip Time (RTT)". Do you know the slowest link in the path for everything you want to conceivably connect to?

The patches were an exercise in trying to max out high bandwidth connections using scp under ideal lab conditions, nothing more.

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

#64

Post by mikeash »

rlpb wrote: post #61
mikeash wrote: post #23

Well, while we're at it, here's my crazy MTU-related war story, although not as crazy as that one! I was troubleshooting with a user of an audio streaming application running over a LAN. The user could stream classical music but not rock music. Seriously. Classical was fine, but when streaming rock, the connection would drop after a few minutes. The application took chunks of audio, compressed them with a lossless co…

Having a smaller MTU is fine. The problem comes when people start blocking the ICMP fragmentation needed packets, presumably due to some assumption that this will in some way help with security.

That's fine for TCP, but not good for a UDP protocol that can't make packets smaller.

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

#65

Post by abalashov »

gwright wrote: 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…

Nice story! I like it! Takes me back to my TDM days too.
Post reply on HN