cagney
January 17, 2023, 4:26am
1
I'm following up Help to install D-LINK DIR-2640 using D-Link Recovery GUI - #8 by dubyte
The same as the original post, from Linux, I tried:
chrome
firefox
curl (like O.P., I did steps 1-4 and not 1-5, before cur)
lynx (it's so old it is text based)
Fortunately, after rummaging around in the basement I found a m/c running windows. It worked fine.
Firstly can I suggest updating https://openwrt.org/docs/guide-user/installation/installation_methods/d-link_recovery_gui making it clear that Windows is likely all that works (and for the curl method steps 1-4, not -5).
But secondly, and more interestingly, given that the low-level lynx and curl both fail, I'm wondering if it is the Linux TCP stack tickling an old bug on the router that is causing this problem.
Thoughts. tcpdump time I guess.
Pico
January 17, 2023, 9:25am
2
cagney:
But secondly, and more interestingly, given that the low-level lynx and curl both fail, I'm wondering if it is the Linux TCP stack tickling an old bug on the router that is causing this problem.
Of what was told in the forum a while ago:
Seems like several browsers on Windows have more graceful handling of this issue.
1 Like
cagney
January 21, 2023, 4:29pm
3
I tried that, no luck
It is Apr 2024 and I'm meeting this issue with a new DIR-2640 D-Link.
when I try with curl 7.81.0 (from a debian distribution for WSL), it seems it is progressing -- and declaring that it will continue with the update -
see below what curl told me.
Few minutes later, it was all working !!!
curl -v -i -F firmware=@openwrt-23.05.3-ramips-mt7621-dlink_dir-2640-a1-squashfs-factory.bin 192.168.0.1
* Trying 192.168.0.1:80...
* Connected to 192.168.0.1 (192.168.0.1) port 80 (#0)
> POST / HTTP/1.1
> Host: 192.168.0.1
> User-Agent: curl/7.81.0
> Accept: */*
> Content-Length: 9568520
> Content-Type: multipart/form-data; boundary=------------------------c5e1db2f13b7dc90
> Expect: 100-continue
>
* Done waiting for 100-continue
* We are completely uploaded and fine
* Mark bundle as not supporting multiuse
* HTTP 1.0, assume close after body
< HTTP/1.0 200 OK
HTTP/1.0 200 OK
< Content-type: text/html
Content-type: text/html
<
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><style type='text/css'>.warning{margin:50px 0;color:red;font-size:22px}</style></head><script type="text/javascript">var percent=1;var Timer;function uiOnload(){Timer=setTimeout("upStatus()",2200);}window.onload = uiOnload;function upStatus(){percent++;if(percent > 100){clearTimeout(Timer);document.getElementById('wait').style.display = 'none';document.getElementById('result').style.display = '';return; }document.getElementById('time').innerHTML = 'Device is upgrading the firmware...' + percent + '%'; Timer = setTimeout('upStatus()',2200);}window.onload = uiOnload;</script><body><center><div><center style='margin:50px 0;color:blue;font-size:24px'>D-Link Router Recovery Mode</center></div><div id=wait><center style='margin:50px 0;font-size:15px'><span id=time>Device is upgrading the firmware... 1%</span></center></div><div id=result style=disp* Closing connection 0
lay:none><center class=warning><span>Upgrade successfully!</span></center></div><hr/><div><center class=warning>WARNING!!</center></div></center><ul><li style='margin:50px 0 10px;font-size:14px'>Do not interrupt the update process,as it may demage the device</li></ul><hr/></body></html>
It seems that in 2017, the authors of curl realized that this 'expect 100 to continue' was broken on many web servers, and decided to remove the curl behavior on newer versions of curl.
I so happen to have WSL / Debian, so trying with curl 7.81.0 was really.
So - I'm not sure which curl version is best, but I had it working on 7.81.0.
thank you to the Forums for the help!
