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
wgetunder 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
wgetis left running, the connection will eventually time out or report that it was reset.
- Using the
wgetnot getting further than starting the HTTP connection. No difference when using the
- Downloading the file with other download managers in Windows results in the same problems. The same is true for downloading with
- 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 188.8.131.52
7.363111 192.168.1.105 -> 184.108.40.206 TCP 36393 > http [SYN] Seq=0 Win=5840 Len=0 MSS=1460 TSV=1389507963 TSER=0 WS=6
7.631255 220.127.116.11 -> 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 -> 18.104.22.168 TCP 36393 > http [ACK] Seq=1 Ack=1 Win=5888 Len=0 TSV=1389508030 TSER=2814359613
7.631300 192.168.1.105 -> 22.214.171.124 HTTP GET /wp-content/uploads/2011/04/tdp-ep2-max-part2.mp3 HTTP/1.0
7.914077 126.96.36.199 -> 192.168.1.105 TCP http > 36393 [ACK] Seq=1 Ack=168 Win=6912 Len=0 TSV=2814359684 TSER=1389508030
> 8.204796 188.8.131.52 -> 192.168.1.105 HTTP [TCP Previous segment lost] Continuation or non-HTTP traffic
8.204803 192.168.1.105 -> 184.108.40.206 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 220.127.116.11 -> 192.168.1.105 HTTP Continuation or non-HTTP traffic
8.258740 192.168.1.105 -> 18.104.22.168 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 22.214.171.124 -> 192.168.1.105 HTTP Continuation or non-HTTP traffic
8.501378 192.168.1.105 -> 126.96.36.199 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 -> 188.8.131.52 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 -> 184.108.40.206 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 -> 220.127.116.11 TCP 36393 > http [FIN, ACK] Seq=168 Ack=1 Win=5888 Len=0 TSV=1389517685 TSER=2814359684 SLE=1441 SRE=5761
46.512795 18.104.22.168 -> 192.168.1.105 TCP http > 36393 [ACK] Seq=5761 Ack=169 Win=6912 Len=0 TSV=2814369332 TSER=1389517685