Download just won't go

K

koffiejunkie

Executive Member
Joined
Aug 23, 2004
Messages
9,757
Reaction score
1,002
Location
Australia
I'm trying to download the SLES images from Novell's site. The first one downloaded about 35MB, now it's just hanging there. Has been for over a day. The strange thing, is the rest of the images coming from the same site (there are 6 image) are downloading alright.

This problem is not limited to this site - I've tried from multiple mirrors. I've gotten this problem with some downloads from sourceforge and a few more sites, even with small files - 50k for example that just goes up to 30k and then stop. Then I ssh into my box at work (on adsl) and download it there - prefectly fine.

So this is an iBurst problem. But what? Anybody else has this problem? Here's my wget output. BTW, I tried curl and different download managers - same problem.

hans@sigaar:~/Downloads/Distros/SLES9> wget --proxy=off -t0 -c http://cache.novell.com/cached/SLES9/SLES-9-i386-RC5-CD1.iso
--13:58:17-- http://cache.novell.com/cached/SLES9/SLES-9-i386-RC5-CD1.iso
=> `SLES-9-i386-RC5-CD1.iso'
Resolving cache.novell.com... 208.172.158.189
Connecting to cache.novell.com|208.172.158.189|:80... connected.
HTTP request sent, awaiting response... 206 Partial Content
Length: 278,036,480 (239,862,531 to go) [application/octet-stream]

13% [+++++++++++ ] 38,173,949 --.--K/s

14:13:19 (0.00 B/s) - Read error at byte 38,173,949/38,173,949 (Connection timed out). Retrying.

--14:13:20-- http://cache.novell.com/cached/SLES9/SLES-9-i386-RC5-CD1.iso
(try: 2) => `SLES-9-i386-RC5-CD1.iso'
Connecting to cache.novell.com|208.172.158.189|:80... connected.
HTTP request sent, awaiting response... 206 Partial Content
Length: 278,036,480 (239,862,531 to go) [application/octet-stream]

13% [+++++++++++ ] 38,173,949 --.--K/s

Thanks
 
koffiejunkie -

I have had terrible experiences with wget and iBurst. You need a download manager, e.g. WINE + Getright to segment the download and have a multi-threaded download - this stalls far less frequently.

I have also had the problem of downloads 'just stopping' close to completion, and then having my download manager simply refuse to resume the download with no error message.

I have also tried this on a Windows machine - same results.

good luck...
 
Dave Thanks,

I have tried downloading with prozilla, and the whole ISO came down, but it failed checksum. While a failed checksum isn't always as bad (I've written an image to disc, created an image of the disc, and compared checksums of the two images - fails sometimes, but always still works), in this case, I can't boot the resulting disc. What are you running on, by the way?

I'm also using IP-COP 1.4.2 - old P-II - works wonderful!
 
I have also had the problem of downloads 'just stopping' close to completion, and then having my download manager simply refuse to resume the download with no error message.

I have also tried this on a Windows machine - same results.
Click to expand...

I had this problem the other day when my harddisk ran out of space. The file is d/l as a temporary file and once downloaded copies and renames the contents (the temp file is then, normally, deleted). Therefore if a 30MB file is d/l then 60MB min. space is required.
 
Last edited:
Broo, thanks for the reply.

wget doesn't work like this - it writes the target file directly, and if you look at the file while the download is in progress, it reports the size downloaded so far, not the final size like I.E. does. Also, it doesn't copy from a temp file or any of that.

Size is definitely not the problem (have about 4GB open) and as I said, it happens even with a 50kB file now and then.

I've also seen the one download resume after a couple of hours, just to get hung again later on. When it does download, it comes in at between 20kB/s and 60kB/s, but the pauses inbetween is a couple of hours each, and then the download only resumes for a couple of minutes to an hour. At this rate it's going to take me a couple of days to download a 650mb image....
 
koffiejunkie said:
I'm trying to download the SLES images from Novell's site. The first one downloaded about 35MB, now it's just hanging there. Has been for over a day. The strange thing, is the rest of the images coming from the same site (there are 6 image) are downloading alright.

This problem is not limited to this site - I've tried from multiple mirrors. I've gotten this problem with some downloads from sourceforge and a few more sites, even with small files - 50k for example that just goes up to 30k and then stop. Then I ssh into my box at work (on adsl) and download it there - prefectly fine.

So this is an iBurst problem. But what? Anybody else has this problem? Here's my wget output. BTW, I tried curl and different download managers - same problem.

hans@sigaar:~/Downloads/Distros/SLES9> wget --proxy=off -t0 -c http://cache.novell.com/cached/SLES9/SLES-9-i386-RC5-CD1.iso
--13:58:17-- http://cache.novell.com/cached/SLES9/SLES-9-i386-RC5-CD1.iso
=> `SLES-9-i386-RC5-CD1.iso'
Resolving cache.novell.com... 208.172.158.189
Connecting to cache.novell.com|208.172.158.189|:80... connected.
HTTP request sent, awaiting response... 206 Partial Content
Length: 278,036,480 (239,862,531 to go) [application/octet-stream]

13% [+++++++++++ ] 38,173,949 --.--K/s

14:13:19 (0.00 B/s) - Read error at byte 38,173,949/38,173,949 (Connection timed out). Retrying.

--14:13:20-- http://cache.novell.com/cached/SLES9/SLES-9-i386-RC5-CD1.iso
(try: 2) => `SLES-9-i386-RC5-CD1.iso'
Connecting to cache.novell.com|208.172.158.189|:80... connected.
HTTP request sent, awaiting response... 206 Partial Content
Length: 278,036,480 (239,862,531 to go) [application/octet-stream]

13% [+++++++++++ ] 38,173,949 --.--K/s

Thanks
Click to expand...


I have had the same problem this weekend .

I reran the mtu tests and have found a new value for MTU = 1400 . This is different from a week ago.

I cannot test on the linux box as I have ( 5mins ago ) just toasted the PSU.

Can someone else check their MTU's and see if they agree.
 
I find my MTU is still at 1432.

I had many stalled downloads when I first started using Iburst, where I had to use background pings or simply continue browsing just to keep the downloads going.

I managed to improve my signal considerably, but even so, since I started using Net Transport I've never had a problem. I've downloaded thousands of files, and several files of size 250MB-350MB at 70MB/s to 120MB/s. It's superfast and has never given up on a download yet.

Net Transport + Iburst = Magic. :)

Won't be so hot though when the cap kicks in. :(
 
A multithreaded download manager. And its free. Here's the site:

http://www.xi-soft.com/default.htm

I can't remember who recommeded it to me, but it was someone on this forum.

*Edit: I looked it up... it was arf9999 *
 
Last edited:
Interesting, I thought I was the only one with this problem and spent a few hours fighting with my router :o

My downloads stall then restart, the restart is instant but it does mess with speed, my downloads tend to start at about 15k and work up to 100k, but with these stalls it just never happens.

I noticed this with Firefox, Flashget wont even start the download, it just hangs from the beginning. wget still seems to be ok :confused:

MTU is set to 1432, will fiddle with it again to see if its the root of all evil.
 
Pinging [196.30.31.120] with 40 bytes ->bytes=40 time=771ms TTL=126
Pinging [196.30.31.120] with 750 bytes ->bytes=750 time=162ms TTL=126
Pinging [196.30.31.120] with 1125 bytes ->bytes=1125 time=545ms TTL=126
Pinging [196.30.31.120] with 1312 bytes ->bytes=1312 time=374ms TTL=126
Pinging [196.30.31.120] with 1406 bytes -> ..fragmented
Pinging [196.30.31.120] with 1359 bytes ->bytes=1359 time=449ms TTL=126
Pinging [196.30.31.120] with 1382 bytes -> ..fragmented
Pinging [196.30.31.120] with 1371 bytes ->bytes=1371 time=693ms TTL=126
Pinging [196.30.31.120] with 1376 bytes -> ..fragmented
Pinging [196.30.31.120] with 1374 bytes -> ..fragmented
Pinging [196.30.31.120] with 1373 bytes -> ..fragmented
Pinging [196.30.31.120] with 1372 bytes ->bytes=1372 time=361ms TTL=126
The largest possible non-fragmented packet is 1372 (1400 - 28 ICMP & IP headers).
You can set your MTU to 1400



Confirmed .... At least for the Kempton tower..
 
koffiejunkie..... to set mtu in linux quickly, login as root and type this:

ifconfig ppp0 mtu 1352

Simple as that. This change is not kept after a reboot. To force it to this MTU size you need to edit the network script files.
 
My cutoff occurs above 1404 bytes, giving an MTU of 1432.

The only caveat about ping testing for MTU is that you have to reset your MTU back to the default 1500 and reboot before testing, otherwise the cut-off will occur at your current setting or lower, but never higher.

It does seem, however, that different base stations have different MTU's. I can't for the life of me understand why WBS would do that.
 
Gatecrasher, sorry for this dumb question, but if your cutoff occurs above 1404, how do you work the MTU of 1432?

I use IP-COP for firwall - it seems to figure out the correct MTU by itself, or a MTU rather. I've seen different MTUs when connecting to ADSL and iBurst and MyWireless, and I've never set it by hand.

I just tried setting it now and it screwed up my connection pretty badly (which made things that much worse as I'm logged in remotely :-)
 
Koffiejunkie,

When you use the ping -f -l n command to send a packet of a set size it does not include the header which is 28 bytes in length. Thus the MTU is MSS+28. So my pings successfully send packets of up to 1404 byte before being fragmented. Adding 28 bytes then gives an MTU of 1432.

In Gary's example, he is getting a cut off above 1372. Adding 28 gives him 1400.

In your case, if IPCOP is doing it for you - let it. If it ain't broken, don't fix it.

Regards,
Maltjunkie. :rolleyes:
 
Last edited:
That's a dumb way to do it. Now you sit with a fixed MTU for all PPPOE connections.
Rather use PMTU discovery, or set the MTU in your pppd config file for the connection.
Look for the pty line
eg.
pty "/usr/sbin/pppoe -S 'TelkomSA' -I eth0 -T 80 -m 1452"

And change -m to whatever you want the MTU for this connection.
Now you can have a different MTU for each ppp connection, especially if you have a combination of ADSL,Sentech and iBurst
 
Thanks guys. I have decided for now that it's just a gremlin on iBurst's side. After lots of ping testing, it seems that IP-COP sets the MTU correctly.

I've noticed, leaving the download on, it after it stalls, it will timeout and keep retrying (if I use -t0 with wget) for a day or so mostly, and then it starts downloading again.

Will see if this persists - once the cap is in place that's going to be a little harder...

Thanks
 
You must log in or register to reply here.
Back
Top
Sign up to the MyBroadband newsletter
X