How do SCP/SSH keep connections alive?

I'm currently downloading a humongous file from a server thousands of miles away. Expected time was about 4 hours with my DSL connection. All of a sudden my wireless connection was dropped. I had no idea why and I was only able to bring it up again by unplugging and plugging in my wireless router. All in all this took at least 4-5 minutes since it took me a while to realize something was wrong, track it down to the hub, and then reboot it. After doing this I checked on my scp copy. Up until rebooting it was hanging there with a message that said "- stalled -". After rebooting the hub a few seconds later the wireless connection came back up and scp continued without any user intervention.

I was quite surprised by this. I would have expected that with the hub down the connection would be lost and could not be reconnected without at least asking for my password. Can anyone shed any light on this?

Comments (11)
  1. Well, the answer is simple. If TCP sees a stall connection, tries for some time until it gives up. I guess interruptions up to a minute can be handled easily. However, if you had been connected dirrectly to a hub, and rebooted it, Windows would see that connection was dropped and release all the TCP/IP addresses bound to the adapter, and would force to close all connections.

  2. In short, this is a feature of TCP/IP and not of SCP/SSH

  3. Marius: The hub was forcefully unplugged and reconnected. And the connection was re-established. What mechanism makes that possible, but also prevents say the following from happening:

    I unplug my hub

    TCP/IP keeps the stalled connected alive (somehow)

    Someone else plugs in a hub and mimics me.

    They then download what I wanted to download.

    I’m very curious 🙂

  4. The scp connection is encrypted (obviously) so any packets that they got that were intended for you would be meaningless. The session keys were exchanged at the start of the conversation, so anyone who jumps in half-way through won’t be able to decrypt the data.

    Besides, this is no different than someone running Ethereal (or whatever) on another computer connected to your hub — they’ll see those packets as well.

    As for TCP/IP keeping the connection alive — it’ll sit there waiting for incoming packets, and retrying the outgoing packets for a reasonable length of time (I’m not sure if it’s configurable, though). After a while, it’ll give up, drop the connection and return ECONNRESET (or whatever).

    If, during that time, the connection comes back up, the retried packets will finally make their way out, and the incoming packets (the other end has been retrying as well) will be allowed in.

  5. AT says:

    Your surprise come from dial-up world.

    Once dial-up connection down – all your connections will be terminated (because dial-up interface IP will be released by OS). It’s almost impossible to continue transfer because once dial-up connection will be restored you will get another IP but there is no way to notify your client/server about IP change and you will be unable to receive data back.

    Similar situation (interrupted transfers) can occur with network cards in case if media-sense enabled. Once cable unplugged or router/hub powered down – network interface will be lost.

    But permanent connections expect to be permanent and believe that some data is simply lost in transit, but connection still present. This way TCP able to recover temporary network outages (like a power down for your wireless hub).

    Why interfaces act in this way ? Because it’s expected that you will have multiple connections and computer must be informed to use remaining resources.

    Consider little A-Bomb explosion near your house and one of your dial-up/DSL are damaged. You must have ability to fight-back fast ;o)

    Single point of failure is not acceptable anymore even for home-business.

    P.S> There was more funny problem with network for me one day ago.

    After installing cumulative (50Mb) patch for remote Solaris server and reboot I was unable to login via ssh/telnet to my box for a long time. Console was not accessible because it’s 9241 km away from me.

    Reason for this ?? One of security patches modified my /etc/pam.conf file in such a way that it attempted to auth me using inaccessible LDAP first.

    Lucky me – there was some kind of timeouts in auth and I was able to login to box after 15 minutes of entering login/password (accidentally, I’ve forgot to close telnet window while was phone-calling ISP tech support to restore HDD data from 60-minutes old backup ;o)

    Experience gained – always use backup power/network/data/logins ;o)

  6. jaybaz [MS] says:

    It’s probably using YModem.

  7. To All: Thanks! Cool stuff to learn about. Technology rules.

Comments are closed.

Skip to main content