DIR-2660 failing to flash

Hello,
I finally managed to experiment a bit more. Eventually, the idea from tmgoblin:

provides a functional path to installing openwrt. The console didn't really provide much insight on why the recovery mode rejects openwrt. I can see the following while trying to flash openwrt:

6: System Enter UBoot to Update Img or Bin.

 abuffer(TX Packet buffer) = 0x8FFE3D40
Trying Eth0 (10/100-M)

 Waitting for RX_DMA_BUSY status Start... done


 ETH_STATE_ACTIVE!!
Got ARP REQUEST, return our IP
Got ARP REQUEST, return our IP
to check image type

=================================================
Check image validation:
Image1 Header Magic Number --> OK
Image1 Header Checksum --> OK
Image1 Data Checksum --> OK

=================================================[check_img_return:0]
image is unencrypto kernel images
*********** len: 1355, s->dataSize: 1355

whereas while trying to flash the stock image I get:

6: System Enter UBoot to Update Img or Bin.

 abuffer(TX Packet buffer) = 0x8FFE3D40
Trying Eth0 (10/100-M)

 Waitting for RX_DMA_BUSY status Start... done


 ETH_STATE_ACTIVE!!
Got ARP REQUEST, return our IP
Got ARP REQUEST, return our IP
to check image type

=================================================
Check image validation:
Image1 Header Magic Number --> OK
Image1 Header Checksum --> OK
Image1 Data Checksum --> OK

=================================================[check_img_return:0]
image is unencrypto kernel images
*********** len: 1355, s->dataSize: 1355
lost ACK
image_flg = 0, length = 17994721

=================================================

updating img...........
ranand_erase: start:180000, len:20000
..ranand_erase: start:1a0000, len:20000
...
....ranand_erase: start:12a0000, len:20000
.(5192)offs=19529728 piece=0 piece_size=37857 rc=0
Done!

and then it reboots. To me, it seems as if it silently rejects the image and stops.

this is the expected result with "U-Boot 1.1.3 (Apr 25 2019 - 14:00:06)" boot loader in a DIR-1960
using recover console by holding reset down while booting
using today's snapshot "openwrt-ramips-mt7621-dlink_dir-1960-a1-squashfs-factory.bin"
it's also followed up by updating the backup copy on the next boot

Got ARP REQUEST, return our IP
*********** len: 1156, s->dataSize: 1156
*********** len: 1156, s->dataSize: 1156
to check image type

=================================================
Check image validation:
Image1 Header Magic Number --> OK
Image1 Header Checksum --> OK
Image1 Data Checksum --> OK

=================================================[check_img_return:0]
image is unencrypto kernel images
*********** len: 1355, s->dataSize: 1355
image_flg = 0, length = 8650866

=================================================

updating img...........
ranand_erase: start:180000, len:20000
..ranand_erase: start:1a0000, len:20000
..ranand_erase: start:1c0000, len:20000
..ranand_erase: start:1e0000, len:20000
..ranand_erase: start:200000, len:20000
..ranand_erase: start:220000, len:20000
..ranand_erase: start:240000, len:20000
..ranand_erase: start:260000, len:20000
..ranand_erase: start:280000, len:20000
..ranand_erase: start:2a0000, len:20000
..ranand_erase: start:2c0000, len:20000
..ranand_erase: start:2e0000, len:20000
..ranand_erase: start:300000, len:20000
..ranand_erase: start:320000, len:20000
..ranand_erase: start:340000, len:20000
..ranand_erase: start:360000, len:20000
..ranand_erase: start:380000, len:20000
..ranand_erase: start:3a0000, len:20000
..ranand_erase: start:3c0000, len:20000
..ranand_erase: start:3e0000, len:20000
..ranand_erase: start:400000, len:20000
..ranand_erase: start:420000, len:20000
..ranand_erase: start:440000, len:20000
..ranand_erase: start:460000, len:20000
..ranand_erase: start:480000, len:20000
..ranand_erase: start:4a0000, len:20000
..ranand_erase: start:4c0000, len:20000
..ranand_erase: start:4e0000, len:20000
..ranand_erase: start:500000, len:20000
..ranand_erase: start:520000, len:20000
..ranand_erase: start:540000, len:20000
..ranand_erase: start:560000, len:20000
..ranand_erase: start:580000, len:20000
..ranand_erase: start:5a0000, len:20000
..ranand_erase: start:5c0000, len:20000
..ranand_erase: start:5e0000, len:20000
..ranand_erase: start:600000, len:20000
..ranand_erase: start:620000, len:20000
..ranand_erase: start:640000, len:20000
..ranand_erase: start:660000, len:20000
..ranand_erase: start:680000, len:20000
..ranand_erase: start:6a0000, len:20000
..ranand_erase: start:6c0000, len:20000
..ranand_erase: start:6e0000, len:20000
..ranand_erase: start:700000, len:20000
..ranand_erase: start:720000, len:20000
..ranand_erase: start:740000, len:20000
..ranand_erase: start:760000, len:20000
..ranand_erase: start:780000, len:20000
..ranand_erase: start:7a0000, len:20000
..ranand_erase: start:7c0000, len:20000
..ranand_erase: start:7e0000, len:20000
..ranand_erase: start:800000, len:20000
..ranand_erase: start:820000, len:20000
..ranand_erase: start:840000, len:20000
..ranand_erase: start:860000, len:20000
..ranand_erase: start:880000, len:20000
..ranand_erase: start:8a0000, len:20000
..ranand_erase: start:8c0000, len:20000
..ranand_erase: start:8e0000, len:20000
..ranand_erase: start:900000, len:20000
..ranand_erase: start:920000, len:20000
..ranand_erase: start:940000, len:20000
..ranand_erase: start:960000, len:20000
..ranand_erase: start:980000, len:20000
..ranand_erase: start:9a0000, len:20000
....ranand_erase: start:9c0000, len:20000
.(5192)offs=10223616 piece=0 piece_size=114 rc=0
Done!


it seems like maybe dlink has updated the boot loader with an extra check
I would think the next step is to add the header model information to the uboot header
& then try to encrypt the file with the tool in the GLP source code
to make a comparable web flash image
if this works an encryption tool may have to be written to do this

as you have serial access you could try loading the inframs image into ram
& if it boots fine you may be able to flash the sysupgrade image via that
but before you flash anything do backup all of your mtd partitions just in case
the only thing is it's nice to have luci compiled info the initramfs image
where the snapshot won't have it
the dir-1960 version is the same you could use it
http://luckys.onmypc.net/openwrt/DIR-1960/2020-10-03/openwrt-ramips-mt7621-dlink_dir-1960-a1-initramfs-kernel.bin
you will get a warning about the firmware model number being different when flashing tho

Hi everyone.

I just bought a D-Link DIR-2660 that I'm currently trying to flash.
I managed to run the telnet exploit, and now I have a working telnet connection.
After uploading the new firmware, I still don't see any file /tmp/firmware.img. Actually, portions of the uploaded file are saved in files like the following

/var/run/lighttpd-upload-wEQKvZ
/var/run/lighttpd-upload-oMqwcr
/var/run/lighttpd-upload-eMv9eR
/var/run/lighttpd-upload-nxDjMg
/var/run/lighttpd-upload-CzEFtP
/var/run/lighttpd-upload-gvI4JC
/var/run/lighttpd-upload-F8Xmrh
/var/run/lighttpd-upload-6snODt

which are then removed.
I'm currently figuring out a way to upload the firmware to later run mtd_write.

Hello,

In my case, the stock FW had wget which means you can download anything directly to the router. If you connect the router in a way that it has internet access, then you can probably even do:

cd /tmp
wget https://downloads.openwrt.org/snapshots/targets/ramips/mt7621/openwrt-ramips-mt7621-dlink_dir-2660-a1-squashfs-factory.bin

Note: editing the link above - in the first version I had pasted the wrong image link - the initramfs-kernel instead of the factory one.

(but do confirm the image sha256sum before flashing it. I also connected a usb flash drive and saved on it all the mtd partitions before flashing anything. I'm not sure how exactly I would use this backup if things would go wrong, but better having it than not)

If you would like to download the image from your local network, starting a temporary http server on another system that listens to <port number> is as simple as running:

python -m SimpleHTTPServer <port number>

in the directory you want to share (the directory on the other system that has the firmware images). This should run on almost any linux distro with python 3.

1 Like

some of the DIR-2660's are not accepting the openwrt firmware
I made a version of the part that makes the header that includes the model & part number
like the factory firmware
my DIR-1960 works with out this so I can't test it
but the code is here

1 Like

master snapshots should now work fine as the header has the extra info

1 Like

Hi, I have the same problem, even with curl I am unable do make the router accept openwrt.

can you help me finding your snapshot to give it a try?

it's just the Master branch snapshots
https://downloads.openwrt.org/snapshots/targets/ramips/mt7621/
with snapshot you have to ssh into it & install luci

I know with a windows browser you get a page back
witch say if the firmware is rejected or starting to upload in to flash
I'm not sure if you get any feed back with curl on Linux

Thank you, I'll try it asap but ... which file I have to use? Kernel, sysupgrade or factory?

No luck. With curl this is the output


curl -v -i -F "firmware=@openwrt-ramips-mt7621-dlink_dir-2660-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.74.0
> Accept: */*
> Content-Length: 8782080
> Content-Type: multipart/form-data; boundary=------------------------9e3a7ac3d8affefe
> 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 remains with red led flashing, if after a while (10-15 minutes) I reboot the router, I'm again in the stock firmware

I own a DIR-2660 A1, Original Firmware 1.11.

I tried with the "two steps" web recovery mode upload, and this is the result.

The recovery seems to be very finicky regarding the firmware upload process, on the COVR devices I could hardly make it work anymore after updating to the latest linux kernel, not sure whether it's browsers or the network stack etc... it tends to work best on windows with ie10 and the "two-step" approach, i.e. reboot after opening the recovery page, and clicking the button after reboot (which prevents the browser from spamming the bootloader with further requests, e.g. favicon.ico and stuff).

Besides, I'm not sure whether the new bootloaders still accept unencrypted images (the COVR-C1200 don't, however they don't check rsa signature).

Does flashing D-Link OEM firmware work via the recovery?
If so, you could try an encrypted version of the latest snapshot (from 2021-10-16), this should also be flashable via the normal web interface from the D-Link firmware.

at this point it may be worth back dating you firmware
download & try to install dlink firmware a version older then current
part of this will be seeing if it will accept the older firmware
and if successful maybe then it may accept openwrt
I have not seen any firmware update the bootloader "U-BOOT"
yet but this could change
note "the RU versions do but different all together source code"

I tried with version 1.04. It was possible to upload the old stock firmware, but when i tried with the snapshot the result was the same as before.

Then the router auto updated to version 1.11 and we are again at the beginning.
Is it possible that the bootloader remains the last one even if I update with an older stock firmware?

@s_2 i tried the encrypted version via usual web interface, but with no success.

I'll try via recovery, but I cannot do it now cause I have to replace the router to not shutdown the network.

In the meantime, thank you all, I think that I'm a bit unlucky or I'm missing something or doing something wrong, it seems very strange to me that I'm the only one unable to upload openwrt to this router

I could indeed reproduce this on a DIR-2660 v1.04, it would not accept the encrypted image.
Tried with and without dlink-headers, tried setting header version to V1.05B01 or something, but version downgrade wasn't the issue either...

I had assumed this would work since many people had commented that encrypted images would work, however that applied mostly to devices from the DIR-8xx range being tested.
@Lucky1 any ideas what else we could check? The only difference aside from the header version field would be the UBI header at 0x400000 in the oem image, maybe the updater eventually started checking for that too? :thinking: :man_shrugging:

I'll see if I can find the time to investigate this further.
Sorry it did not work out yet :slightly_frowning_face:

the only thing i can think of is to try the initramfs-kernel.bin
as this is one partition is may allow upload "no UBI"
next would be to sysupgrade to the normal version
this would have to all be done via ssh

may just need to find out what dlink firmware is accepted via the recover interface
encrypted non encrypted etc

there is a way to move forward but risky
turn off auto update
back date to old version
get an older bootloader & flash it via the old firmware version
making an assumption that maybe the new version is updating the boot loader
then flash it via the old boot loaders recover interface
but thi is guessing a lot