Right since I started using Tooway, my monitoring device (a RIPE Atlas monitor) has been recording periods of packet loss on the Tooway network. I’ve raised this several times with Avonline’s technical support but never received a meaningful answer, or indeed one that demonstrates that they understand the issues. Periods of packet loss do not appear to correlate with heavy precipitation.
So, until proven otherwise, we have to assume that this is an inherent property of their service. So what does that mean?
- Loss of secure web services: my outgoing email (secure connection to Google) frequently fails; bank, messaging connections that use SSL regularly keel over as the connection has effectively been interrupted to the point where it drops and therefore can’t be re-established without re-authentication. Annoying.
- Router failover. I use a dual-WAN router, with our ADSL connection (such as it is) running as a backup. The router is continually testing the Tooway connection and switches to ADSL should the Tooway connection drop. This is happening on a fairly regular basis.
As it’s just happened, I can have an immediate look at what’s going on with the network:
Firstly, ping records to google.com – these taken immediately after the point when my ssl connections failed:
PING www.google.com (173.194.40.115): 56 data bytes
64 bytes from 173.194.40.115: icmp_seq=0 ttl=52 time=841.753 ms
64 bytes from 173.194.40.115: icmp_seq=1 ttl=52 time=759.992 ms
64 bytes from 173.194.40.115: icmp_seq=2 ttl=52 time=760.803 ms
64 bytes from 173.194.40.115: icmp_seq=3 ttl=52 time=761.905 ms
64 bytes from 173.194.40.115: icmp_seq=4 ttl=52 time=757.925 ms
64 bytes from 173.194.40.115: icmp_seq=5 ttl=52 time=796.410 ms
64 bytes from 173.194.40.115: icmp_seq=6 ttl=52 time=795.633 ms
Request timeout for icmp_seq 7
64 bytes from 173.194.40.115: icmp_seq=7 ttl=52 time=1234.462 ms
64 bytes from 173.194.40.115: icmp_seq=8 ttl=52 time=1193.086 ms
64 bytes from 173.194.40.115: icmp_seq=9 ttl=52 time=1152.343 ms
64 bytes from 173.194.40.115: icmp_seq=10 ttl=52 time=751.312 ms
64 bytes from 173.194.40.115: icmp_seq=11 ttl=52 time=760.803 ms
64 bytes from 173.194.40.115: icmp_seq=12 ttl=52 time=751.184 ms
64 bytes from 173.194.40.115: icmp_seq=13 ttl=52 time=749.693 ms
64 bytes from 173.194.40.115: icmp_seq=14 ttl=52 time=750.580 ms
64 bytes from 173.194.40.115: icmp_seq=15 ttl=52 time=746.799 ms
64 bytes from 173.194.40.115: icmp_seq=16 ttl=52 time=746.015 ms
^C
— www.google.com ping statistics —
18 packets transmitted, 17 packets received, 5.6% packet loss
round-trip min/avg/max/stddev = 746.015/841.806/1234.462/165.004 ms
Having shown that we are going through a period of packet loss, now for the recent packet loss history for my connection (red stripes are periods of packet loss):
There does appear to be some lag on RIPE’s reporting, hence the current time not showing in red.
Now, having demonstrated that we have ongoing packet loss issues, the next step is to look what’s been happening with our network connection itself:
| Internet Address: | Controller Connected: | Connect at: | Disconnect at: | Connected time: | Disconnected time (until next connection): |
| 176.227.xxx.xxx | ctr-ams04, NL | 2013-11-12 10:43:18 UTC | (still connected) | 0d, 2h, 56m | (still connected) |
| 176.227.xxx.xxx | ctr-ams04, NL | 2013-11-11 15:57:33 UTC | 2013-11-12 10:40:50 UTC | 0d, 18h, 43m | 0d, 0h, 2m |
| 81.174.xxx.xx | ctr-ams04, NL | 2013-11-10 14:07:26 UTC | 2013-11-11 15:51:37 UTC | 1d, 1h, 44m | 0d, 0h, 5m |
| 176.227.xxx.xxx | ctr-ams04, NL | 2013-11-05 10:23:07 UTC | 2013-11-10 13:57:32 UTC | 5d, 3h, 34m | 0d, 0h, 9m |
| 81.174.xxx.xx | ctr-ams04, NL | 2013-11-05 10:13:58 UTC | 2013-11-05 10:20:20 UTC | 0d, 0h, 6m | 0d, 0h, 2m |
| 176.227.xxx.xxx | ctr-ams04, NL | 2013-11-05 04:53:09 UTC | 2013-11-05 10:03:56 UTC | 0d, 5h, 10m | 0d, 0h, 10m |
| 176.227.xxx.xxx | ctr-ams04, NL | 2013-11-02 10:32:59 UTC | 2013-11-05 04:51:17 UTC | 2d, 18h, 18m | 0d, 0h, 1m |
| 176.227.xxx.xxx | ctr-ams04, NL | 2013-11-01 05:42:50 UTC | 2013-11-02 10:30:44 UTC | 1d, 4h, 47m | 0d, 0h, 2m |
| 81.174.xxx.xx | ctr-ams04, NL | 2013-10-31 18:55:19 UTC | 2013-11-01 05:39:58 UTC | 0d, 10h, 44m | 0d, 0h, 2m |
| 176.227.xxx.xxx | ctr-ams04, NL | 2013-10-31 13:44:34 UTC | 2013-10-31 18:39:19 UTC | 0d, 4h, 54m | 0d, 0h, 16m |
| 176.227.xxx.xxx | ctr-ams04, NL | 2013-10-29 20:10:08 UTC | 2013-10-31 13:36:48 UTC | 1d, 17h, 26m | 0d, 0h, 7m |
| 176.227.xxx.xxx | ctr-ams04, NL | 2013-10-28 14:28:46 UTC | 2013-10-29 20:08:06 UTC | 1d, 5h, 39m | 0d, 0h, 2m |
| 81.174.xxx.xx | ctr-ams04, NL | 2013-10-28 11:20:43 UTC | 2013-10-28 14:17:36 UTC | 0d, 2h, 56m | 0d, 0h, 11m |
| 176.227.xxx.xxx | ctr-ams04, NL | 2013-10-28 11:02:25 UTC | 2013-10-28 11:19:55 UTC | 0d, 0h, 17m | 0d, 0h, 0m |
| 176.227.xxx.xxx | ctr-ams04, NL | 2013-10-25 23:49:10 UTC | 2013-10-28 11:01:30 UTC | 2d, 11h, 12m | 0d, 0h, 0m |
| 81.174.xxx.xx | ctr-ams04, NL | 2013-10-25 19:08:40 UTC | 2013-10-25 23:47:10 UTC | 0d, 4h, 38m | 0d, 0h, 2m |
| 176.227.xxx.xxx | ctr-ams04, NL | 2013-10-22 18:11:07 UTC | 2013-10-25 19:05:22 UTC | 3d, 0h, 54m | 0d, 0h, 3m |
| 81.174.xxx.xx | ctr-ams04, NL | 2013-10-22 15:36:54 UTC | 2013-10-22 18:09:10 UTC | 0d, 2h, 32m | 0d, 0h, 1m |
| 176.227.xxx.xxx | ctr-ams04, NL | 2013-10-22 12:47:40 UTC | 2013-10-22 15:29:09 UTC | 0d, 2h, 41m | 0d, 0h, 7m |
| 81.174.xxx.xx | ctr-ams04, NL | 2013-10-21 21:52:52 UTC | 2013-10-22 12:40:18 UTC | 0d, 14h, 47m | 0d, 0h, 7m |
| 176.227.xxx.xxx | ctr-ams04, NL | 2013-10-10 17:15:44 UTC | 2013-10-21 21:47:14 UTC | 11d, 4h, 31m | 0d, 0h, 5m |
| 176.227.xxx.xxx | ctr-ams04, NL | 2013-10-10 16:01:57 UTC | 2013-10-10 16:55:11 UTC | 0d, 0h, 53m | 0d, 0h, 20m |
| 5.61.xxx.xxx | ctr-ams04, NL | 2013-10-10 08:43:47 UTC | 2013-10-10 13:38:30 UTC | 0d, 4h, 54m | 0d, 2h, 23m |
| 5.61.xxx.xxx | ctr-ams04, NL | 2013-10-09 11:30:30 UTC | 2013-10-10 08:42:32 UTC | 0d, 21h, 12m | 0d, 0h, 1m |
| 5.61.xxx.xxx | ctr-ams04, NL | 2013-10-07 16:25:22 UTC | 2013-10-09 11:24:44 UTC | 1d, 18h, 59m | 0d, 0h, 5m |
| 5.61.xxx.xxx | ctr-ams04, NL | 2013-10-04 22:07:48 UTC | 2013-10-07 16:19:48 UTC | 2d, 18h, 12m | 0d, 0h, 5m |
Looking at this, you can see when the connections drop and when they fail to the point where the backup ADSL line kicks in – anything showing an IP address starting with 81.174… is the ADSL in use.
And today is a bright clear day in Scotland. It’s also clear and bright in Turin, where Tooway’s primary ground link is apparently situated, with no precipitation in the last 24 hours.
So this remains a continuing concern with Tooway’s network and with Avonline’s ability to respond to a reported problem.