reliability of our internet connection

Question

I have a server in a remote location. While connecting to that machine using SSH, it keeps getting disconnected saying:

Read from remote host XXXX: Connection reset by peer
Connection to XXX closed.

I am doubting this as a problem with the Internet connection at our end because ping to that machine shows request time outs in random intervals. I tried even pinging Google which also showed request time out.

How can I confirm that it's a problem with the Internet/what is the actual error?

More info:

We have an VPN tunnel between our network and the remote network. So I can ssh remote machine using one of the local IP that it gains. and tracert to that finishes in 2 hopes with success.

Answer 1

i would recommend that you use the traceroute command. On windows, it is shortened to 'tracert'

for example, open up the command prompt and type the following (-d means dont do DNS lookups):

tracert -d <your server ip address>

this will give you a list of all the hops that a TCP packet hits along the way to the target. The last successful hop before you get a timeout will give you an idea of where the internet is failing. It could be your wifi, your ISP, or something else.

Another idea is that sometimes the SSH connection can be dropped because the system thinks the connection is idle and that its ok to drop it. This could also be a setting in your modem. But i think traceroute will give you a good idea of the failure point. If you never catch a failure with traceroute, i'd say that perhaps something is activly dropping your idle connection. Look into Keep-Alive type settings in your Wifi Router/DSL modem etc.

But post back your findings and lets see if we can help you figure this thing out.

good luck.

Answer 2

I'd advise installing something like smokeping. That'll give you stats over a period of time that you can use to go beat your ISP into providing a half decent service.

Answer 3

Run a network capture on your machine while connected to the remote machine. When the disconnect occurs look in the capture for a TCP RST (reset) from the remote machine. If you find it then the problem is with the remote machine. If you don't then the problem is somewhere in the connection between the two.

Answer 4

With all due respect, I don't mean that tracert fails every time. I mean that when one host in the path fails to respond to a tracert it doesn't mean that that host is the problem, and if you use tracert a lot you'll see that invariably there always seems to be a host in the path that doesn't respond.

The issue here is with the connection intermittently dropping. If it were down hard than using tracert and ping would be a good choice. Ping and tracert are good triage level tools but they're not going to help discover the cause of intermittent problems. Tracert (as it's name implies) is a tool for tracing the route to a remote host, and by it's nature can tell you if a path does or does not exist. Tracert is not a diagnostic tool that can tell you why a host isn't responding or is dropping packets. The only way to glean that information is to run a network capture on both ends of the connection, and ideally if possible, on each link in the path.

If I run a constant ping and a constant tracert to a remote host and I get a failed ping response from the remote host and at the same moment see an intermediate host in the tracert stop responding, does that mean that that intermediate host is the problem? No it doesn't and there would be now way to correlate the two events unless I was running a network capture on every link in the path and could analyze the data at the packet level.

I was simply suggesting to start the troubleshhoting with the known, measurable components, which are the two hosts at either end of the connection.

I know everyone has their own opinion and my intention is not to start a war, so my apologies if anyone takes offense.

Answer 5

Do you have anything in place that might be throttling or rate-limiting incoming SSH connections on the machine, such as iptables (Linux) or inetd.conf (FreeBSD)? What happens if you wait 5 or 15 minutes before retrying the connection?