Linux - GeneralThis Linux forum is for general Linux questions and discussion.
If it is Linux Related and doesn't seem to fit in any other forum then this is the place.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Elbow in the side of the ribs type comment.
Actually there are many many Martins around, very popular name, have not found an extremely bad egg in the bunch yet.
Originally Posted by nx5000
> Try a more robust downloader, maybe wget for command line
Thanks, that worked great.
Okay, here's a harder problem. This has happening a couple/few times over the past couple years. Downloading a file over the dialup connection, the download just stops, even with wget. I think wget always stops at the same spot for any given file as Firefox does. The process doesn't exit, it just sits there not doing anything visible. In this case, Firefox and wget both stopped just two SECONDS shy of completing another bz2 file
It's not necessarily the file format though. I think I once had the same problem with a pdf file.
As far as firefox when downloading, or wget is concerned it is just a sequence of bytes - you are quite correct that it doesn't have anything to do with the file type.
I remember with horror the days of dialup - always dropping connections at the worst possible time. I found that the biggest two factors governing reliability of dialup service were phone line quality and service provider... it takes a while to find a combination which works. I had a line from comcast and no where I dialled to, the connection would drop periodically. Make sure you have call waiting turned off, and any other service which interjects in a connected call.
With wget you can use the --continue option to complete a partial download, and you can use the --tries option to specify a number of times to retry.
As far as firefox when downloading, or wget is concerned it is just a sequence of bytes - you are quite correct that it doesn't have anything to do with the file type.
I've heard, I have no recollection where, that the dialup modem has a certain bit sequence that it interprets as a command to terminate the transmission. The only filetype issue I can think of is that maybe some formats don't contain that special code, if it exists, while others do. That's just desperate speculation, though. I have no idea for sure.
Quote:
I remember with horror the days of dialup - always dropping connections at the worst possible time.
The connection is fine, except for this download (and the poky speed).
Great galloping gefiltefish[1], a miracle seems to have occurred. There's a .tgz version of the file I'm trying to download, so I tried that one with wget. Firefox didn't appear to do anything with that file. It would just sit there with the Firefox tab "Loading" for possibly upwards of an an hour or more, until my ISP cut off my connection, without even displaying the download popup window.
wget at least displayed its progress, which was much more reassuring. At the 99% point, it also stopped, so for a while there, all hope appeared to be lost. However, after sitting there for another half hour or so, it eventually retried. Here's the transcript:
wget wins again! (checksum is correct) So I guess this thread is now a matter of curiosity rather than panic. It would be nice for future reference to know where the culprit is, now that we know it applies to both .bz2 and .tgz formats.
I would imagine that if the modem traffic data can contain a hangup sequence, the modem protocol would be designed to escape it somehow... just like it is possible in C programs to put a double quote in double quotes by prefixing it with a backslash, for example: "like \" this". I would expect this to be automatic.
If you are able to retrieve the file on re-try this doesn't seem likely to be the case.
There does seem to be /something/ fishy going on if it always happens at 99%. If you start to download a different file which is twice as large, does it happen after the same number of bytes, or at 99% of the new file too? Curious!
I would imagine that if the modem traffic data can contain a hangup sequence, the modem protocol would be designed to escape it somehow... I would expect this to be automatic.
It certainly would be convenient.
Quote:
If you are able to retrieve the file on re-try this doesn't seem likely to be the case.
There does seem to be /something/ fishy going on if it always happens at 99%. If you start to download a different file which is twice as large, ...
This doesn't happen with just any random file. Historically, it's only happened a couple/few times out of scores of downloads over several years.
Quote:
... does it happen after the same number of bytes, or at 99% of the new file too? Curious!
It's 99% of the file in both cases, even though they differ by about 2MB (tgz 11MB, bz2 9MB). That might point away from file format or content, unless there's some content that bz2 can't compress any more than or differently from tgz and gets inserted at the end of the file in both formats. Other than that, it looks like some more insidious phenomenon. Maybe it's GvR's fault
Also there is this eicar test files. It is not a virus but is designed to test your antivirus so it is triggered as a "test virus"
Try to download them here (http version should do): http://www.eicar.org/anti_virus_test_file.htm
then try with replacing http by https and see if commands finish.
Excerpts:
Code:
...
Connecting to kernel.org|204.152.191.37|:443... connected.
ERROR: Certificate verification error for kernel.org: self signed certificate
ERROR: certificate common name `localhost.localdomain' doesn't match requested host name `kernel.org'.
...
Connecting to kernel.org|204.152.191.5|:443... connected.
ERROR: Certificate verification error for kernel.org: self signed certificate
ERROR: certificate common name `localhost.localdomain' doesn't match requested host name `kernel.org'.
...
Quote:
Also there is this eicar test files. It is not a virus but is designed to test your antivirus so it is triggered as a "test virus"
Try to download them here (http version should do): http://www.eicar.org/anti_virus_test_file.htm
I've never knowingly installed any antivirus software. What am I supposed to do, just download the four files at the bottom of the page and look for warnings? And is it safe without my having installed any antivirus code?
The eicar stuff is a dummy program but its signature is known by antiviruses. It is a safe way to test an antivirus. I thought downloading these small files could show if there is an antivirus on the way.
But I guess it's a ppp problem. Eventhough I've worked on ppp I've never really understood everything to be honest
You should look at the /var/log/pppd.log <-- can't remember the exact logfile name
Change the IP adresses if you post them here.
For the unescape stuffs, it is handled by asyncmap (some caracters are translated), usually set to a000; but I guess you didn't touch the configuration.
This only happens for compressed files?
When I had problems with ppp, I usually went to comp.protocols.ppp groups, there are some very skilled persons overthere.
You should look at the /var/log/pppd.log <-- can't remember the exact logfile name
I don't see anything like that, and the man page says pppd uses syslog. There doesn't seem to be much in `grep pppd /var/log/syslog*`, or anything about pppd in /etc/syslog.conf.
Quote:
This only happens for compressed files?
I don't think so. I think it happened to a pdf file last year sometime.
Quote:
When I had problems with ppp, I usually went to comp.protocols.ppp groups, there are some very skilled persons overthere.
Sounds good. I probably won't ask until/unless I have the problem again, but it helps to know where to ask. Thanks.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
Incomplete bz2 download
