Perplexing problem downloading files

D

dahduh

New Member
Joined
Apr 22, 2007
Messages
5
Reaction score
0
Location
Cape Town
Hello all,

I have been trying to trace a problem downloading files via ADSL and am now completely confounded as to what the problem could be. Perhaps one of you has an idea.

Over the past few weeks I have found 7 files I am unable to download from 3 different sites via HTTP. For each file, when I try to download the download always stops at the same spot for that file. There is then a pause of about 3 1/2 minutes, then the downloads completes without error, but with an incomplete file. There does not appear to be an error reported from TCP/IP. For the different files, the spot at which the download stops is at a different place in the file with no obvious pattern (one file stops downloading at 24%, another at 95%, etc.)

The obvious answer would be that there is an intercepting HTTP proxy with a bad cached file. Indeed, I am going via SAIX and they run an intercepting proxy. However, these are the test and observations:

1. Throughput is excellent, no packet loss during download.
2. I've downloaded using IE, FireFox, DAP, and CURL. Same result.
3. I’ve used cURL.exe to turn off proxy caches using HTTP header “Cache-Control: no-cache” directives; same result.
4. I’ve proxied through anonymous proxies, even proxies in another country. Same result.
5. I’ve tried through two different computers and a PDA on my network. Same result.
6. I’ve tried two different ISP accounts, one from Bucknet and another from Telkom; same result, but note that both ISPs use SAIX.
7. I’ve put in a completely different make & model ADSL modem. Same result.
8. I’ve downloaded one of these files fine to my PDA via GPRS, and I've confirmed with one of the site administrators that he can download the file ok, so it's not a problem with the remote servers.
9. I've turned off my router long enough to get a new IP address, no change.
10. I've asked two friends to try download via _their_ ADSL connections, and they have no problem. But I don't know details of their connections.
11. I've only had this problem for MP3 files so far, and it appears to have started sometime in the last 2-3 weeks.

I've looked at one of these files in detail; here's the URL:

http://cache.libsyn.com/skepticsguide/skepticast2007-04-10.mp3

The interesting thing is that this file stops downloading at 6,341,907 bytes, but if I resume the download from 6,342,349 bytes as follows, then I can download most of the rest of the file:

curl.exe -o t.mp3 --continue-at 6342349 http://cache.libsyn.com/skepticsguide/skepticast2007-04-10.mp3

If I start 1 byte earlier, then the download freezes up.

So what's going on? I'm close to 100% certain this is not a proxy cache problem. It almost looks like something out there is sniffing packets and if it discovers something in the stream it doesn't like, then it starts throwing away all subsequent packets. But this is absurd, I know of no service out there that would do that; and why am I the only person who seems to be experiencing this problem?

Or am I; is there anyone else out there that is having this problem? If your ISP is using SAIX, could you please try to download the above file? And if you have any brilliant ideas, let me know. Below are some dumps and traces from one of the other problem files.

As a reward for your efforts, the podcast above is worth listening to!

Thanks,
Dahduh.

------------------------------------------------------
tracert skeptoid.com

Tracing route to skeptoid.com [72.32.102.215]
over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms 192.168.0.1
2 14 ms 14 ms 13 ms dsl-240-64-01.telkomadsl.co.za [41.240.64.1]
3 15 ms 14 ms 15 ms wbs-ip-er-1-fe-12-0-1-612.telkom-ipnet.co.za [196.43.23.194]
4 15 ms 15 ms 15 ms wbs-ip-er-1-fe-12-0-1-612.telkom-ipnet.co.za [196.43.23.194]
5 14 ms 14 ms 14 ms wblv-ip-lir-1-ge-0-0-1.telkom-ipnet.co.za [196.43.11.194]
6 496 ms 502 ms 496 ms ash-ip-dir-equinix-pos-4-2.telkom-ipnet.co.za [196.43.18.54]
7 * 621 ms 645 ms so-3-0-1.ar1.DCA3.gblx.net [208.49.224.161]
8 450 ms 453 ms 456 ms 64.209.102.42
9 445 ms 451 ms 452 ms vlan901.core1.dfw1.rackspace.com [72.3.128.21]
10 459 ms 458 ms 449 ms aggr2a.dfw1.rackspace.net [72.3.129.7]
11 452 ms 445 ms 452 ms briandunning.com [72.32.102.215]


HTTP request
============
curl --trace-ascii t.log --header "Cache-Control: no-cache" -o t.mp3 http://skeptoid.com/audio/skeptoid-4039.mp3


GET /audio/skeptoid-4039.mp3 HTTP/1.1
User-Agent: curl/7.12.0 (i386-pc-win32) libcurl/7.12.0 OpenSSL/0.9.7d zlib/1.2.1
Host: skeptoid.com
Pragma: no-cache
Accept: */*
Cache-Control: no-cache <--- added in case Pragma: no-cache ignored


HTTP response
=============

HTTP/1.1 200 OK
Date: Sat, 21 Apr 2007 18:49:20 GMT
Content-Length: 10261222
Content-Type: audio/x-mp3
Server: Apache/2.0.52 (Red Hat)
X-Powered-By: PHP/5.1.6
Via: 1.1 rrba-ip-pcache-5 (NetCache NetApp/6.0.5D2), 1.1 cbs-cache2 (NetCache NetApp/6.0.5P1)

(then follows MP3 file in packets of 1452 bytes)
0000: 49 44 33 02 00 00 00 01 5f 49 43 4f 4d 00 00 68 ID3....._ICOM..h
0010: 00 65 6e 67 69 54 75 6e 4e 4f 52 4d 00 20 30 30 .engiTunNORM. 00
<snip>

(the last packet received is 1452 bytes. Then there is a delay of serveral minutes, after which
the TCP/IP connection is closed apparently without error. However, 5624212 bytes remain to read.)
 
Are you absolutely positive that your machine is free from spyware and/or viruses and trojans?

The fact that it just affects MP3 files, that it started recently, and that you're the only one affected makes me suspect that there's something ELSE interfering with the download.

If you know someone with server space, you might ask them to host an mp3 file, and then to host the same mp3 file but with a different extension (.tst should work for the purposes of this test) and then see what happens when you try and download both files.
 
The mystery deepens!

To briefly answer your question about spyware/trojans, I downloaded one of the problems files fine by connecting a machine that normally connects via ADSL, to connect via a GPRS modem. Also, note that I have reproduced the problem on 2 desktop computers and a PDA; the two desktop machines each run different anti-virus software, and the PDA uses a different operating system. So I think we can rule out any kind of malicious infection.

I took Xarog's suggestion and copied a file I obtained via GPRS to a web server hosted in South Africa. Then if I try to download the file via HTTP, it stalls as before. I can see from the HTTP header that SAIX's intercepting proxy is no longer involved. But get this: If I try to download the file via FTP it _still_ fails! Even wierder, note that I can copy the file _to_ the web server via FTP no problem, but when I try and copy it back from the server the download stalls. I also tried renaming the file to .tst, and this had no effect.

So I think that rules out intercepting proxies being the problem.

I then chopped the file into 100k chunks, and loaded the chunk on which the download fails onto the server. And guess what: I can't download that chunk! The download stops in the chunk at about the same data location that the download stopped in the full file. This chunk now no longer has any MP3 header, and is named "T005.007".

I think this proves pretty definitively that whatever is causing this problem is related to some kind of pattern in the data that is being transmitted; and that it seems to be looking only at downstream packets, not upstream. For example, maybe somebody is running some kind of software to prevent the transmission of worms, and it is picking up false positives in audio files. But I can't believe servers are yet fast enough to do this, and about 1/3 of the podcasts I listen to are being intercepted, which would cause general havoc for a lot of people. And why have I only experienced problems in MP3 files so far? And surely any competent scanner would be blocking both uploads _and_ downloads?

Still as perplexed as ever.
 
This problem is indeed very very strange. More so that its only occurring with your system. I really cant think of any software that will look at that deep to stop a download mid way. That ain't anything on your computer either.

If a router can do that with a hardware firewall maybe, but I don't think in most configurations it will do it, let alone can do it.
 
I have never in my life heard of anything like this, and frankly, right now I am totally stumped.

:confused:
 
the same thing happened to me a few weeks back trying to download a mp3.

but my mp3 source differs, it was an http stream (basically hitting preview on a song on some website) and the stream failed at the same point everytime for no reason, tried leeching it using 3rd party software, same result, with no ability to resume the damaged chunk.

then tried a different approach, the preview could be leeched from 2 different sources (2 different ip's, assuming that they were 2 different servers accessing the same file server), this still failed at the same point, i eventually gave up. but i was'nt able to get the entire mp3, and place it somewhere else to test whether the download worked from another location.

basically, u're not alone, and its not spyware
 
I have had websites which change the URL on occasion, or every 20 minutes.
 
I've isolated a sequence of 11 bytes that can't be downloaded. Here's a hex dump (the corresponding characters appear to the right):

0000: 3c 3c 3c 3c 30 00 00 00 00 3c 3c <<<<0....<<

If I put these 11 bytes in a file all by itself, then when I try to download the file from the web server via FTP in binary transfer mode, the transfer pauses for about a minute, then ends without error; but no bytes are transferred. Remove a single byte or change a single byte, no problem.

Bizarrely, the first few times I tried to download it via HTTP it didn't download; but on all subsequence attempts it downloads ok.

This looks suscpicously like an escape sequence to me; maybe somebody left a router is in some kind of debug mode? Has anybody bumped into a router that uses a bunch of '<' symbols as part of an escape sequence?
 
You wouldn't happen to know by any chance if the DSLAM you're connected to is one of the DSLAMS that telkom has recently performed planned maintenance upon?
 
Those 11 bytes that u c, would be encapsulated in the body of an http request, which is in turn in the body of a tcp packet, which resides in an ip datagram, your everyday adsl router is only gonna route packets at the ip layer (headers only), and then maybe the firewall would kick in and examine some tcp/udp headers, but besides that, i doubt its gonna do any concrete stateful packet inspection, hence it would never see the 11 byte escape code
 
I have to say that I am mightily impressed you managed to isolate the problem to a sequence of 11 bytes.
 
Hey guys,

I'm also having the exact same problem, and it's only happening with MP3 files. I have a SAIX connection. I have tried using an anonymous proxy service, but that only works sometimes.

dahduh, if you manage to sort out the problem, please let us know. There are a few podcast episodes that I'm dying to download.
 
Hi hardcode,

My ISP has done a bunch of tests and handed the problem over to SAIX for investigation. To quote:

"The only assumption we have is that the problem might be at the DSLAM. This we cannot be certain of until SAIX have had a look at the problem, which we trust they will diligently do."

Don't we all. I will keep you posted.
 
dahduh, I think the problem might be at the DSLAM. I tried to download the same MP3's using my IS account, and I got the same result - the download stopped when it reached a certain point.

Anyway, I've tried to download it using an anonymous proxy service again - this time using one that uses SSL (https://proxyget.com). It seems to be working (the file is still currently downloading, but the download has gone beyond the point at which it stopped previously). I guess, since the link between the browser and the proxy is encrypted, whatever was dropping my downloads previously is no longer seeing that byte sequence you mentioned. Hope this helps.

Time to catch up on those podcasts!
 
Last edited:
Perplexing download problem - Solution!

Hi All,

At last this problem has been resolved by Telkom ADSL. It was eventually isolated to the DSLAM. When my ADSL line was moved to a different DSLAM, the problem went away; not, however, when it was moved to a different port on the original DSLAM. Apparently each DSLAM has 32 ports, so it is probable that all 32 lines on the same DSLAM have the problem.

I don't know what measures Telkom has taken to fix the problem on this particular device. If you are in the Plumstead Cape Town area, then perhaps this is your problem.
 
As I see it, they've got two choices : flash the DSLAM's software and get rid of the bug, or replace the DSLAM.

Either way, I hope you don't mind if I take credit for mentioning the possibility that the DSLAM was the cause of the problem first... :p
 
dahduh said:
I've isolated a sequence of 11 bytes that can't be downloaded. Here's a hex dump (the corresponding characters appear to the right):

0000: 3c 3c 3c 3c 30 00 00 00 00 3c 3c <<<<0....<<
Click to expand...

Fascinating! I made a file of that byte sequence, and thankfully had no problem. I'd love to know why your DSLAM was cramping on it.
 
You must log in or register to reply here.
Back
Top
Sign up to the MyBroadband newsletter
X