2

I am unable to keep several types of long running connections open from my office LAN (ADSL) and I need to convince the service provider that there is a real problem. Standard pings and traceroutes do not indicate any issues, I need something more advanced.

Whenever I launch a long running MySQL query from my box (PHP or MySQL Workbench) over the ADSL line to a server on the Internet, the driver seems to disconnect. MySQL Workbench freezes and requires a force quit. PHP never returns any results and must be killed. The same query from my home works just fine, always.

Remote desktop connections over the ADSL line get dropped often and I need to reconnect 15 times a day. This does not happen from home. SSH connections also drop.

I am using a Mac but my colleague with Windows has the same problem. How can I diagnose and prove the problem?

GGGforce
  • 669
  • 2
  • 7
  • 10
  • Run a packet capture to capture traffic at the ingress of your network and look for TCP RST packets at the time of a disconnection. If these are long idle connections I suspect a firewall somewhere to be terminating these idle connections. – joeqwerty Jan 27 '15 at 17:55
  • This smells like the problem. The technician arrives tomorrow and I'll have him investigate. – GGGforce Jan 28 '15 at 09:58
  • The problem went a away with a newer router. I think the old one couldn't handle all the simultaneous connections and was dropping the older ones. I never actually diagnosed the problem. – GGGforce Feb 17 '15 at 12:28
  • Also, some ISPs [have been known](https://www.eff.org/wp/packet-forgery-isps-report-comcast-affair) to inject RSTs. For anyone else finding this, it might be worthwhile to run a packet capture at both ends and see if one end gets RSTs that the other end isn't sending. – Parthian Shot Mar 08 '16 at 16:03

3 Answers3

3

You should try your route to the host, one tool to do that is mtr, a traceroute that shows you latency to each hop on the route.

In mac you can install with homebrew

brew install mtr    

then

mtr example.com    

And you would be able to see witch host is dropping packets.

2

Pings should show the issue if you craft the ping request well enough, and leave it running in the background pointing it at a log file, for example;

ping -t -w 250 -4 -l 1024 google.com >> log.txt

will ping google.com with a 1k packet and a 250ms timeout. Some hosts will not accept packets larger than 32/64 bytes, but the larger the packet the better ping will simulate actual usage, and give you dropped packets if that is what is occurring. Don't worry about the size of the reply.

IceMage
  • 1,336
  • 7
  • 12
  • To note, I had a similar issue with a dedicated hosting provider, since the host was in the EU, I had to prove "micro-cuts" (I'm not familiar with the exact term) were occurring on their trans-Atlantic connection. That's a headache. – IceMage Jan 27 '15 at 17:31
  • This is a command for windows FYI. – IceMage Jan 27 '15 at 17:48
  • Yeah, working on translating that to Mac OS now. – GGGforce Jan 27 '15 at 18:16
  • mac osx (no need to tell it to keep going, it will by default) - https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man8/ping.8.html Here's what I came up with, probably wrong tho - ping -n -s 1024 -W 250 – IceMage Jan 27 '15 at 18:28
  • What should be the expected output to discard a problem? – marianosz May 20 '19 at 14:17
0

You could use a bandwidth monitor software, and run it over the course of 24hrs. This should give you a pretty precise reading of your bandwidth status.

Alternatively you could also copy the log for your ssh connections. As these disconnect upon every microcut, it should prove you are actually experiencing highly recurring connection loss.

The information form your ssh sessions will be in /var/log/system.log

and in Lion and earlier versions of OS X, the file would be in /var/log/secure.log

Hope that helps

BootFracture
  • 53
  • 1
  • 1
  • 3