15

I recently spent the Easter bank holiday with my parents, who live in a very rural area in the UK. They have a (terrible) ADSL internet connection, which is run over several kilometres of dodgy copper and is periodically interrupted when nearby farmers reverse their tractors into the phone lines.

I noticed that their router was repeatedly dropping the pptp handshake, and renegotiating it, killing the connection effectively. This was frustrating. So, in an attempt to avoid going insane, I told it to double the minimum acceptable SNR margin and handshake for lower speeds:

$ telnet 192.168.1.1
Trying 192.168.1.1...
Connected to 192.168.1.1.
Escape character is '^]'.
U.S. Robotics Wireless MAXg ADSL Gateway
Login: ***********
Password: 
> sh

BusyBox v1.00 (2006.02.17-20:30+0000) Built-in shell (msh)
Enter 'help' for a list of built-in commands.


adsl configure --snr 200; exit


Connection closed by foreign host.

This improved matters, and the thing got a (somewhat) stable, if incredibly slow, pipe to the outside world:

$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
64 bytes from 8.8.8.8: icmp_seq=0 ttl=55 time=3236.679 ms
64 bytes from 8.8.8.8: icmp_seq=1 ttl=55 time=3699.541 ms
...

At about this point, real life intervened and I then spent several hours playing with cats, looking at cat gifs on my phone, actually talking to my family, etc. I forgot that I'd left this ping process running, and came back about a day later to hit ctrl-c.

The summary statistics shown floored me:

--- 8.8.8.8 ping statistics ---
103074 packets transmitted, 100564 packets received, 2.4% packet loss
round-trip min/avg/max/stddev = 32.986/3034.479/3600577.732/87527.276 ms

As you can see, the maximum recorded response time for an ICMP packet making a short transatlantic hop to Google's DNS server is 3600577.732 ms. That's almost exactly an hour, and certainly far longer than ping's default timeout.

How on Earth can this be? Is it accurate? What router will happily hold onto a packet for sixty minutes before sending it on its way? Why wasn't this packet dropped? Is it the result of an overflow from the 8-bit packet counter combined with large latencies?

Finally, I would be interested to know if there is any code of conduct in the UK stating that consumer ADSL connections are expected to have less latency and better traffic management than that by RFC 1149 and RFC 2549 ;-).

Community
  • 1
Landak
  • 151

2 Answers2

4

The ICMP packet and response for the ping are each 32 bytes long, so it seems for an hour-long ping that every byte was taking almost a minute to transmit.

This is only explainable by very generous error retry count (your doing?), coupled with very slow router and a painful wait or retries for each and every transmitted byte.

The Internet Protocol (IP) transmits data by datagrams and tries not to send partial ones. Once transmission is started, it will wait by default for 200 milliseconds for more bytes to be added to the datagram. Past that time, the software/firmware will send whatever it has as one datagram. In the case of the hour-long ping time, the packet payload may have been as small as one byte. As long as data was still arriving, the connection will not be terminated by the two participating sides.

What you can do :

  • If other phones, fax, or other devices are connected to the same phone line, check if they are protected by DSL filters. Be sure you don't put a filter on the line going to your DSL modem.
  • Try another router - once you've got yourself a bad device there's absolutely nothing you can do about it except throw it out and get something better.
  • If no other router is available, contact you ISP - they can run useful tests from their side.
  • If the ISP finds nothing, try to demand anyway a replacement router/modem.
  • If the same problem occurs with another router, get in touch with the phone company.

It can be quite complicated to locate a problematic switch, as it can be with the phone company, but the ISP may also have their own switches. Normally a problem with a switch is area-wide which helps locate the malfunctioning switch. But in a rural area where not too many subscribers are using that switch this might go undetected. If some neighbors are using the same ISP, try to find out what their connection is like.

harrymc
  • 498,455
0

I see this case very much related to data congestion management although a very bad managed one for whatever the reason could be. To my understanding, there is packet buffer along the transmission system -badly managed, which causes this anomaly in the ICMP echo request/reply packets.

So the combination of having a bad congestion managment policy with having a ping session opened for hours can obviosuly result in such weird scenario.

More information about congestion management here.

Tamadite
  • 128