DIR-2660 failing to flash

@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

Tried encrypted initramfs, not accepted either.

Serial output on unsuccessful update:


filename:/tmp/firmware.img


SERVER_SOFTWARE:(null)


boundary:---------------------------90040011733351880632355659523

offset:234

endoffset end:9177115

n :1024

len:60,0x7fb0bf5c,---------------------------90040011733351880632355659523--


len:64,0x7fb0bf58,
-----------------------------90040011733351880632355659523--


endoffset:9177051 - offset:234 = 9176817,strlen(p)=64

ftruncate_file,filename:/tmp/firmware.img

it just ends there, the ftruncate_file output comes from /sbin/fwupload.cgi, which performs some checking (basically just compares the header to SHRS or 0x27051956) but should output yet another error if something is bad, otherwise it calls exit(0);, so I assume the error must come after that. The actual call to imgdecrypt and mtd_write comes from prog.cgi / prog_cgi (which exists twice in the filesystem presumably by error), this is triggered via HNAP GetFirmwareValidation.

The only checks performed there are whether the (decrypted) header starts with 0x17051958 and if the model_name attribute matches.

When performing an update to D-Link OEM firmware, no further helpful outputs are visible on the serial console:

filename:/tmp/firmware.img


SERVER_SOFTWARE:(null)


boundary:---------------------------3300305816167528672416854074

offset:193

endoffset end:18028878

n :1024

len:59,0x7fbaec7d,---------------------------3300305816167528672416854074--


len:63,0x7fbaec79,
-----------------------------3300305816167528672416854074--


endoffset:18028815 - offset:193 = 18028622,strlen(p)=63

ftruncate_file,filename:/tmp/firmware.img
[system]: led internet off
Disable WanLedControl in timer

[system]: gpio l 3 0 4000 0 1 4000
[system]: led internet high blinkfast
[system]: gpio l 4 1 1 1 1 4000

So this will require further investigation someday... =/

Going back to my early Python implementation, manually decrypting official firmware again, it turns out that they must indeed have changed the RSA key for DIR-1960 and DIR-2660, unlike the DIR-8xx and old COVR devices. The tool dlink-sge-image will still decrypt the image, but also should have printed a warning about the RSA mismatch.

By the way, I recently found the firmware for COVR-X1860 on the ftp, also built by SGE (unlike DIR-X1860 by AlphaNetworks), which seems to use even a different AES key; i.e. the image currently won't decrypt at all.

So, I think the next steps here are indeed to figure out the format required by the recovery, which (at least for old COVR devices) does only decrypt AES, without checking RSA.

if it has that "public.pem" file it uses the PUBLIC KEY located in that file
and to encrypt the firmware to be valid you need the matching PRIVATE KEY

I got the default openwrt 21.02.0 file
manually edited the header
you can try this
http://luckys.onmypc.net/openwrt/DIR-2660/openwrt-21.02.0-ramips-mt7621-dlink_dir-2660-a1-squashfs-factory.bin

thank you, tomorrow I'll try and I'll let you know.

I tried the linked firmware on a DIR-2660 via curl. Same result :confused:

what is the full model number of you router ?
what version of firmware is currently installed ?
country of purchase may help as well ?
and have you found any firmware that will install via it's recovery page ?

DIR-2660 ver. A1

1.11

USA

No - I can downgrade to firmware 1.01 via the normal admin page. But then i try to flash anything else and it won't flash. Also as someone else said it will eventually update itself to 1.11.

I would be interested to know if any of the dlink firmware will upload via the recover interface ?

No - I was not able to go from 1.11 -> 1.01 via recovery interface (I use curl - browser has never worked for me). Only way i can downgrade is from the admin tab in the original firmware.

as primarily a windows user I just use Firefox "Private browsing mode"
but I know could not get Firefox on Debian to work witch seemed weird
but i have not needed to try or use the curl method
but if you can't recover with dlink firmware then openwrt won't work ether

i can only do limited test as the DIR-2660 is not available in Australia
I do have the DIR-1960 same PCB but it's boot load is like the early DIR-2660's
witch would except blank headers
others found later versions need the model number in the header
maybe they are updating it even further now

I DID IT!!!!!!

Thank you all!!! the epiphany was this last message from Lucky1!

The problem is not in the firmware, is in linux. I can't figure why, but I downgraded the firmware on the router to release 1.04 via web interface, and USING FIREFOX ON WINDOWS I was able to flawlessy upgrade the firmware to the current standard openwrt version via the recovery form.

Now it works with luCI and all the stuff.

I think that we have to write about this strange behavior on the dir-2660 page of the openwrt wiki

1 Like

Good work! Must be a linux issue because i tried your process above trying FF and curl and still no dice. I even tried with a Windows VM :slight_smile:

Jbbs thank you for your insight, it saved me a great deal of frustration.

The recovery form did not work on my router, so I had to logon to the d-link interface, which then presented pages to force you through there setup process and updated to the latest software. I discovered later that you can circumvent the d-link proces and go directly to the Firmware Update page by entering https://192.168.0.1/UpdateFirmware.html in the browser after the login page.

I downgraded the firmware to d-link's 1.04, the recovery gui was visible again and I updated to openwrt like normal.

So after hearing all these success stories I formatted a windows machine and gave it a try again using the methods you outlined above. Sure enough - worked exactly as described. For whatever reason, Linux is the problem. I didn't go far enough to try masking my user agent while in Linux so for now I would just use windows for this process.

3 Likes

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.