2

I have a shaped 384kbps ADSL connection (entry-level "broadband") with an ISP, which runs over the compulsory analog voice line provided by the only telephone provider in the country. "Shaped" means that certain protocols (such as peer-to-peer traffic) are given a lower priority on the network. This question relates to normal HTTP downloading, not peer-to-peer downloading.

For the last few months I have been experiencing stalled HTTP downloads from various sites which do not resume. I first noticed the problem in iTunes under Windows XP, but have done extensive testing to try to locate the problem. About 5% of files I download stall and do not resume.

Until recently, these have all been MP3 files (podcasts), but the problem has also appeared when downloading an Android app. In the list below, "the file" refers to any of several files which stall and will not resume.

  • The problem appears even when using the latest version of iTunes.
  • The router and computer/s have been restarted many times; the problem has persisted over several months.
  • Downloading the file with wget under Windows or Linux (connected by wireless or wired connections) results in the file downloading to the given point and then the throughput drops to zero. On some occasions, if wget is left running, the connection will eventually time out or report that it was reset.
  • Using the -c flag with wget results in wget not getting further than starting the HTTP connection. No difference when using the --no-cache flag.
  • Downloading the file with other download managers in Windows results in the same problems. The same is true for downloading with curl under Linux.
  • The file can be downloaded successfully elsewhere, either from a computer on a different network entirely, or from a computer elsewhere using the same ISP, so a broken version of the file is not stuck in a cache, nor is the file on the source server incomplete.
  • I have taken my router to another location with the same ISP and the file downloads successfully. I have brought a router from that location to my location and the file stalls and won't resume.
  • My ISP has upgraded my line and account to 1mbps to test with. This has not solved the problem.
  • HTTP browsing, streaming of audio or YouTube video and most downloads other than MP3 files seem unaffected. An Android app would not complete recently. When I connected to a local wireless hotspot run by a different company, the app download completed.
  • If I download the file on a remote machine on a different network and transfer it over a secure connection (scp) the file downloads successfully.
  • If I connect to a local wireless hotspot run by a different ISP, the file will download. If I attempt to resume a stalled download over the hotspot link, it will resume. If I then pause that file and connect back to my ADSL, the file will then complete, as it has passed the point at which it stalls.
  • If I connect with an unshaped test account from my ISP or with a test account with another ISP, the file stalls and will not resume.
  • If a representative from the ISP tries to download the file from their test machine, it downloads successfully.

I experienced the same problem a few years ago, and after much discussion, my ISP eventually agreed to ask the telephone provider to move my line to a different port on the local DSLAM. This solved the problem back then. Despite all the testing and discussion this time, my ISP reports that the telephone provider will not move my line, as the line tests they have performed indicate the line conditions are good and that the line is performing normally.

(A post on a local forum several yeas ago from someone else with a similar problem suggested that a particular sequence of bytes was "hanging" some hardware equipment. The poster claimed to have done some tests and to have determined the exact sequence of bytes. I'm not suggesting that this is the cause of my stalled downloads, but this explanation does appear to fit the facts very well.)

Therefore, can I conclude that the problem is related to some hardware upstream from me, but independent of my ISP? What else could be causing this problem?

Additional information: Here is a trace from the command-line WireShark program as a file stalls (created several months ago). This file stalls right at the beginning and doesn't even start; other than that, the symptoms are identical to files which stall at some other point. I'm assuming the problems I am experiencing now are caused by the thing that caused them before. I've sent these logs to my ISP on a number of occasions, but did not hear anything back. I don't know if this log capture is useful though. I've indicated in bold the point at which the download stalls:

7.052812 192.168.1.105 -> 192.168.1.254 DNS Standard query AAAA www.diablopodcast.com
7.322756 192.168.1.254 -> 192.168.1.105 DNS Standard query response
7.322816 192.168.1.105 -> 192.168.1.254 DNS Standard query AAAA www.diablopodcast.com
7.362412 192.168.1.254 -> 192.168.1.105 DNS Standard query response
7.362450 192.168.1.105 -> 192.168.1.254 DNS Standard query A www.diablopodcast.com
7.363014 192.168.1.254 -> 192.168.1.105 DNS Standard query response A 89.107.69.77
7.363111 192.168.1.105 -> 89.107.69.77 TCP 36393 > http [SYN] Seq=0 Win=5840 Len=0 MSS=1460 TSV=1389507963 TSER=0 WS=6
7.631255 89.107.69.77 -> 192.168.1.105 TCP http > 36393 [SYN, ACK] Seq=0 Ack=1 Win=5792 Len=0 MSS=1452 TSV=2814359613 TSER=1389507963 WS=7
7.631269 192.168.1.105 -> 89.107.69.77 TCP 36393 > http [ACK] Seq=1 Ack=1 Win=5888 Len=0 TSV=1389508030 TSER=2814359613
7.631300 192.168.1.105 -> 89.107.69.77 HTTP GET /wp-content/uploads/2011/04/tdp-ep2-max-part2.mp3 HTTP/1.0
7.914077 89.107.69.77 -> 192.168.1.105 TCP http > 36393 [ACK] Seq=1 Ack=168 Win=6912 Len=0 TSV=2814359684 TSER=1389508030
> 8.204796 89.107.69.77 -> 192.168.1.105 HTTP [TCP Previous segment lost] Continuation or non-HTTP traffic
8.204803 192.168.1.105 -> 89.107.69.77 TCP [TCP Dup ACK 80#1] 36393 > http [ACK] Seq=168 Ack=1 Win=5888 Len=0 TSV=1389508173 TSER=2814359684 SLE=1441 SRE=2881
8.258734 89.107.69.77 -> 192.168.1.105 HTTP Continuation or non-HTTP traffic
8.258740 192.168.1.105 -> 89.107.69.77 TCP [TCP Dup ACK 80#2] 36393 > http [ACK] Seq=168 Ack=1 Win=5888 Len=0 TSV=1389508187 TSER=2814359684 SLE=1441 SRE=4321
8.501360 89.107.69.77 -> 192.168.1.105 HTTP Continuation or non-HTTP traffic
8.501378 192.168.1.105 -> 89.107.69.77 TCP [TCP Dup ACK 80#3] 36393 > http [ACK] Seq=168 Ack=1 Win=5888 Len=0 TSV=1389508247 TSER=2814359684 SLE=1441 SRE=5761
10.649646 192.168.1.105 -> 89.107.69.77 TCP 36392 > http [FIN, ACK] Seq=1 Ack=1 Win=3353 Len=0 TSV=1389508785 TSER=2814347814 SLE=40321 SRE=142562 SLE=36001 SRE=37441 SLE=20161 SRE=21601
36.377648 192.168.1.105 -> 89.107.69.77 TCP 36392 > http [FIN, ACK] Seq=1 Ack=1 Win=3353 Len=0 TSV=1389515217 TSER=2814347814 SLE=40321 SRE=142562 SLE=36001 SRE=37441 SLE=20161 SRE=21601
46.249883 192.168.1.105 -> 89.107.69.77 TCP 36393 > http [FIN, ACK] Seq=168 Ack=1 Win=5888 Len=0 TSV=1389517685 TSER=2814359684 SLE=1441 SRE=5761
46.512795 89.107.69.77 -> 192.168.1.105 TCP http > 36393 [ACK] Seq=5761 Ack=169 Win=6912 Len=0 TSV=2814369332 TSER=1389517685

Improve this question
8
  • This might be a silly question given all the other things you have tried but I can't see any explicit mention of it: have you tried using another computer on your ADSL connection? (longshot, but if you're connecting to your router via a wired ethernet connection, maybe your network card or its driver is faulty)
    – Caspar
    Dec 9, 2011 at 2:00
  • Yes, downloads stall from two desktops connected by cable and from a laptop, netbook and smartphone connected by wireless.
    – SabreWolfy
    Dec 9, 2011 at 7:10
  • Are you certain that the telephone wiring in your house is reliable? Have you tried using Tor as the encryption may bypass whatever reliability problems your isp has...
    – Mokubai ♦
    Dec 9, 2011 at 8:15
  • @Mokubai: It could be the telephone wiring running to the router. Transferring a stalled file over scp works. I would not be able to use Tor as a permanent solution, as encrypted traffic is not shaped, so transferring large amounts of encrypted traffic on a shaped account would be in contravention of the FUP/AUP/T&C.
    – SabreWolfy
    Dec 9, 2011 at 10:14
  • Was the problem a couple of years ago with the same ISP? Are you still connected to the same DSLAM, have you moved house or done anything else to otherwise inadvertently change your DSLAM port?
    – Caspar
    Dec 9, 2011 at 15:48

1 Answer 1

Reset to default
0

This was solved by using a different model of router (from the same manufacturer). The alternate router which I tested (mentioned in my question) was a very similar model to my router; mine was running the latest firmware. The problem appears to be with the software/firmware in that range of models.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .