SCP and HostMonster
I've been working on this far more than I intended, but I'm trying to find a way to make it work for me while at work. The problem is that the one factor that is key to this problem is the configuration of the HostMonster server - and I have no control over that at all. I have a few more details, but they aren't surprising: if I set:
Compression no
in my ~/.ssh/config file, then I don't get any bytes transferred, but if I set:
Compression yes
then I get at least some data transferred. This makes some sense - if I'm sending it in batches, I send the first batch and unpack it, and then I wait for some handshaking. I'm not getting that handshaking. If I don't compress it, then I'm trying to send the first byte and that's getting there, but with no handshake, it's probably not enough for the OS to write out to the filesystem.
There's nothing specific about this from my Googling, but I have a feeling that it's one of two things:
- some path from Ameritech to HostMonster is different and messing things up by bad transfers, or something like that
- an update the HostMonster staff did to OpenSSH
My reasoning for the first is that the path from Comcast to HostMonster does not have to be the same as the path from Ameritech to HostMonster. At some point, one of the pipes could have changed, been reconfigured, etc. and this would be the source of the problem. My reasoning for the second is that the HostMonster box has to be in the mix for a failure, and the box has been rebooted recently so it's not a stalled process, etc.
It's possible that there's something with the routing in the building, but then I'd have problems no matter where I went, so I don't think it's that. Also I know they'd have to go through a lot of paperwork to get any changes approved/done. So it's unlikely that someone 'forgot' about it.
I still haven't heard from the HostMonster technical support guys, and they said 24 hours, but I'm guessing that they are a little behind schedule on this - or are trying to track it down. In either case, I'm really at their mercy on this one.
I'm running a few traceroutes from work and home and I'll compare them to see where the paths converge, as they have to as they both eventually get to the same box. We'll see what happens.
UPDATE: I did this traceroute from work to the HostMonster machine (deleting the times and removing any repeated lines with no information):
1 192.168.100.1 (192.168.100.1)
2 192.168.1.1 (192.168.1.1)
3 adsl-68-22-220-1.dsl.chcgil.ameritech.net (68.22.220.1)
4 dist2-vlan60.chcgil.ameritech.net (67.38.101.35)
5 bb2-g7-0.chcgil.ameritech.net (151.164.242.210)
6 151.164.93.49 (151.164.93.49)
7 asn2828-xo.eqchil.sbcglobal.net (151.164.249.98)
8 p5-0-0.rar1.chicago-il.us.xo.net (65.106.6.133)
9 p6-0-0.rar2.denver-co.us.xo.net (65.106.0.25)
10 p0-0-0d0.rar1.denver-co.us.xo.net (65.106.1.73)
11 65.106.6.82.ptr.us.xo.net (65.106.6.82)
12 207.88.83.102.ptr.us.xo.net (207.88.83.102)
13 ip65-46-48-66.z48-46-65.customer.algx.net (65.46.48.66)
14 * * *
...
64 * * *
and I did this one from home to the HostMonster machine (again, deleting the times and removing the repeated lines at the end):
1 www.routerlogin.com (192.168.1.1)
2 10.1.1.1 (10.1.1.1)
3 * * *
4 ge-1-37-ur01.romeoville.il.chicago.comcast.net (68.86.118.213)
5 te-3-1-ur02.wchicago.il.chicago.comcast.net (68.87.230.113)
6 te-8-4-ur01.wchicago.il.chicago.comcast.net (68.87.231.213)
7 * te-2-1-ar01.elmhurst.il.chicago.comcast.net (68.87.230.105)
8 68.87.230.254 (68.87.230.254)
9 68.86.90.178 (68.86.90.178)
10 68.86.90.181 (68.86.90.181)
11 te-4-2.car2.chicago1.level3.net (4.71.182.33)
12 ae-14-55.car4.chicago1.level3.net (4.68.101.136) \
ae-24-56.car4.chicago1.level3.net (4.68.101.168) \
ae-14-51.car4.chicago1.level3.net (4.68.101.8)
13 wbs-connect.car4.chicago1.level3.net (4.71.102.26)
14 tg9-2.cr01.chcgildt.integra.net (209.63.114.37)
15 * * *
16 tg13-4.cr01.sttlwatw.integra.net (209.63.114.69)
17 tg13-1.cr01.ptleorte.integra.net (209.63.114.98)
18 tg13-4.cr02.ptleorte.integra.net (209.63.114.142)
19 tg13-1.cr02.boisidpz.integra.net (209.63.114.18)
20 tg13-4.cr01.boisidpz.integra.net (209.63.114.13)
21 tg13-1.cr01.slkcutxd.integra.net (209.63.114.30)
22 tg9-1.ar10.slkcutxd.integra.net (209.63.114.254)ms
23 gw0-cust-bluehost-com.slkc.eli.net (70.97.59.22)
24 * * *
...
64 * * *
So I look at this and don't see them meet up anywhere, so this isn't going to help me in seeing where the paths diverge. I also looked at the details of the ping packets from the two locations to HostMonster - one is 46 hops, the other is 49, both are in the sub-80 msec range. No help there.
I can't look at the reverse paths because they are behind routers - Oh, I could look at the HostMonster to local pops, but when I try that I get Operation not permitted - no doubt for security reasons.
I've tried copying the file from HostMonster to my machine at work and that works great! Once again, it gets more confusing. I can copy from there, but I can't copy to there. Also, I looked and they don't support WebDAV or WebDAV HTTPS - which are both supported by Transmit/Coda.
I've tried running:
scp -l 10 file dest:
which is meant to limit the bandwidth used to 10kbps, and that sent the first packet and then stalled out. Same behavior as always.
As a final test, I tried using the FTP Manager on the ControlPanel for the HostMonster domain, and even that doesn't allow me to upload the file. There's something very wrong going on. And depending on the data you look at, it appears as though every component is working. But clearly, I'm not looking at the tests correctly.