Posted: Sun Jul 16, 2017 15:54 Post subject: Bug in wget? (or perhaps DFU???)
I think there is a bug in wget or, perhaps, I don't really understand how it works... (I'm leaning towards the latter).
I've got an install script for my YAMon tool that downloads all of the files to the users' router. The script uses `curl` if it is available but since many DD-WRT variants do not, it falls back to `wget`. I've gotten reports from several of my `wget` users about incomplete downloads. After updating my TPLink Archer C9 (v1) firmware to DD-WRT v3.0-r32597 std (07/08/17), I can now replicate the issue myself (hooray!).
If I make the following call to get a local copy of a 101KB HTML file:
I get just the first 37KB of the file and if I repeat the call, there is no difference... the file size remains at 37KB (no matter how many times I repeat it).
The file size is 37KB after the first call
It increases to 74KB after the second and 101KB after the 3rd.
After the 4th call, I get the following error:
wget: server returned error: HTTP/1.1 416 Requested Range Not Satisfiable
(and that repeats as long as the file exists)
The `-c` option continues the download (as expected per the documentation) but why is it necessary at all - i.e., why doesn't the first wget call download the entire file?!? Is there a bug in wget or it is just a flaky server at one end of the connection?
Posted: Sun Jul 16, 2017 16:22 Post subject: Re: Bug in wget? (or perhaps DFU???)
al_c wrote:
I think there is a bug in wget or, perhaps, I don't really understand how it works... (I'm leaning towards the latter).
I've got an install script for my YAMon tool that downloads all of the files to the users' router. The script uses `curl` if it is available but since many DD-WRT variants do not, it falls back to `wget`. I've gotten reports from several of my `wget` users about incomplete downloads. After updating my TPLink Archer C9 (v1) firmware to DD-WRT v3.0-r32597 std (07/08/17), I can now replicate the issue myself (hooray!).
If I make the following call to get a local copy of a 101KB HTML file:
I get just the first 37KB of the file and if I repeat the call, there is no difference... the file size remains at 37KB (no matter how many times I repeat it).
The file size is 37KB after the first call
It increases to 74KB after the second and 101KB after the 3rd.
After the 4th call, I get the following error:
wget: server returned error: HTTP/1.1 416 Requested Range Not Satisfiable
(and that repeats as long as the file exists)
The `-c` option continues the download (as expected per the documentation) but why is it necessary at all - i.e., why doesn't the first wget call download the entire file?!? Is there a bug in wget or it is just a flaky server at one end of the connection?
Posted: Sun Jul 16, 2017 16:33 Post subject: Re: Bug in wget? (or perhaps DFU???)
EA6500v1 wrote:
al_c wrote:
I think there is a bug in wget or, perhaps, I don't really understand how it works... (I'm leaning towards the latter).
I've got an install script for my YAMon tool that downloads all of the files to the users' router. The script uses `curl` if it is available but since many DD-WRT variants do not, it falls back to `wget`. I've gotten reports from several of my `wget` users about incomplete downloads. After updating my TPLink Archer C9 (v1) firmware to DD-WRT v3.0-r32597 std (07/08/17), I can now replicate the issue myself (hooray!).
If I make the following call to get a local copy of a 101KB HTML file:
I get just the first 37KB of the file and if I repeat the call, there is no difference... the file size remains at 37KB (no matter how many times I repeat it).
The file size is 37KB after the first call
It increases to 74KB after the second and 101KB after the 3rd.
After the 4th call, I get the following error:
wget: server returned error: HTTP/1.1 416 Requested Range Not Satisfiable
(and that repeats as long as the file exists)
The `-c` option continues the download (as expected per the documentation) but why is it necessary at all - i.e., why doesn't the first wget call download the entire file?!? Is there a bug in wget or it is just a flaky server at one end of the connection?
BusyBox 1.26.2 in the firmware you are currently using has that bug. The commit to fix that (https://git.busybox.net/busybox/commit/?id=a6f8651911716d1d1624712eb19e4f3608767c7) was done the day after 1.26.2 was released and should be fixed in the latest version of BB 1.27.0 that was released less than two weeks ago.
THX - that was fast!
The final comment in the bug report says
"commit a6f8651911716d1d1624712eb19e4f3608767c7e which fixes this will be backported to 1.26.x...
Hopefully that means we won't have to wait for BB 1.27.0 in DD-WRT.
Yeah!! I can not wait for the updated busybox to appear in the firmware.