@RolandoMagico on your git, which version did you compile?
Hello @zimmie,
which version do you need? The Git branch/hash of the build?
the branch/hash
All the builds I did until now are on the main branch. You can check the file version.buildinfo in the releases for the commit hash which was used.
1 Like
Does it matter which way do I take to flash device? Standard GUI or Recovery?
Is there a way to install the stock OS back again or is it one way process?
There shouldn't be a difference in flashing via standard or recovery web interface.
I'm not sure how reverting back to stock firmware is currently working. The firmware images from D-Link are encrypted. I assume that neither OpenWrt nor the recovery interface support encrypted images. So the D-Link images must be decrypted before using it in the recovery web interface? Maybe @s_2 has more information regarding this topic.
Update: I tried it out: The recovery mode doesn't accecpt the encrypted D-Link firmware. But with dlink-sge-image from the firmware-utils (see Add support for D-Link COVR-X1860 - #39 by s_2), it's possible to decrypt it and flash it via recovery interface.
@s_2: Please correct me if I'm wrong regarding the encrypted images. I also get some errors during decryption, is it intended:
SHA512 vendor does not match decrypted payload padded with vendor key.
free(): double free detected in tcache 2
Abgebrochen (Speicherabzug geschrieben)
1 Like
Thanks for checking this. Did anyone test already 802.11r with this Device and OpenWRT? I will connect them all to switch as I have ethernet connectivity in each room in my house.
Yes, the bootloader only accepts decrypted images, which are not even available from D-Link, so there is no official way to recover.
Curious, it looks like the message comes from a redundant call to fclose(), although this error does not change anything here in terms of functionality (it would exit anyways on the next line, the file is already decrypted at that point).
Did you get this result from decrypting any official firmware downloaded from D-Link?
Yes, I think I used COVR-X1860_fw_reva_102b01_ALL_multi_20230630
FWIW, i decrypted the original firmware available from D-Link using s-2‘s firmware-utils branch. While there was no error during decryption, the recovery UI wouldn‘t accept the image and always bootloop into recovery again. Flashing OpenWRT again worked though. Wonder why the decrypted firmware is not accepted.
Which image from D-Link did you use? I can try to reproduce the issue with my devices if you want.
The only one available from D-Link: https://ftp.dlink.de/covr/covr-x186x/driver_software/COVR-X1860_fw_reva_102b01_ALL_multi_20230630.zip (see their support area for COVR-1860)
Ok, I took a device with stock firmware, downloaded openwrt-ramips-mt7621-dlink_covr-x1860-a1-squashfs-factory.bin. OpenWrt is up and running.
Started recovery mode, uploaded COVR-X1860_RevA_Firmware_102b01_decrypted.bin: Stock firmware is running again.
Information about COVR-X1860_RevA_Firmware_102b01_decrypted.bin:
- Size: 16384352 Bytes
- SHA256: db053c31bdfdd75fc7022f997347224b9d8a61b6fa8ab42a5930f89797065c9a
Apologize my stupidity, i was missing the "-d" switch and ended up with a double-encrypted image 
Decryption stated the same double-free error but eventually i got the same hash on the decrypted firmware. Will give it a try.
Do you think it's worth keeping the devices for tinkering? Tbh my old AVM setup (Wifi 5) has way better coverage and stability than the COVRs. Same spot, same devices. My iPad wouldn't even connect to the COVRs at all. Thinking about reverting to stock and selling them again.
Don't know if it makes sense to keep the devices in your case. I use it for Gluon/Freifunk and depending on the location I have better coverage than my currently running FritzBox 4040 (also running on OpenWrt/Gluon). Coverage highly depends on the local situation, but it's strange that the iPad doesn't connect at all. Any information in the logs?
Not much, there was some lines about the iPad being disconnected after inactivity and there are quite a few threads about issues with iOS devices and OpenWRT, but strangely my ancient iPad Mini 2 (~10 years old) is happy connecting to OpenWRT. It's just the more recent one, running iPadOS 16. All other Apple devices (quite a lot tbh) also work fine despite the not-so-stable bandwidth allocation, but that's another issue.
For reference, i configured 802.11r on wpad-wolfssl and was also running DAWN to help not-so-smart clients with roaming.
I'm willing to dig a bit deeper into the issue. I'm quite eager to replace the AVM stuff with a free (libre) AX solution, especially on such a bargain.
So i gave it another try and finally resolved the issue with the iPad - it seems it doesn't work well in mixed WPA2/WPA3 + 802.11r mode. Reverting to WPA2 fixed it.
Next issue though is with the second COVR: i flashed OpenWRT (same image as on the first one) through the D-Link webinterface and also through the recovery UI, but each time LUCI does not come up on 192.168.1.1, or any other IP i tried. Going back to recovery UI or even D-Link stock firmware works fine though, so i'm pretty sure the hardware is not faulty. Any hints?
I would assume ping or ssh will not connect to the device as well?
What's the color / pattern of the top LED, do you see it flashing orange (first quickly, then slower) during boot, and does it turn white eventually?
Just to be sure: you did set the regdomain to e.g. Germany in the wireless settings in LuCI? I think it's somewhere on the second tab. Otherwise, international settings (i.e. lower transmit power) would be selected by default.
Thanks for the hints, i resolved it finally.
It was probably a bad mistake on my side, a bit lengthy to explain but... after giving up yesterday because of the iPad i gave it another try today and uploaded a backup config from device A into device B (because i simply took the wrong one out of the box). This led to having the network interfaces / devices having the same MAC address although a different IP was configured. My switch and probably also FritzBox must have been totally confused having two devices with identical MAC addresses in the ARP cache and so network traffic was always routed to the wrong COVR, which in turn had a different IP than expected.
I eventually solved it by entering OpenWRT failsafe mode (the button bootup method) and changing the MAC address after mount_root. After the next reboot, it became available and i am now finishing configuration.
I've also set country to DE to see if it helps. Thanks so far! This looks way more promising now than yesterday.
That's curious, usually the device MAC should not be written to UCI settings (unless you explicitly chose to override it), so that configuration remains portable between devices (which is the whole point of having UCI, e.g. to have an identical backup device in place). For some targets, I remember there used to be scripts that would fix wifi MAC in userspace by overriding it in the UCI settings (e.g. for ath10k chips, when the caldata contained an invalid MAC, but even that was fixed in the meantime). Did you actually mean to change the MAC here, or is this indeed still an issue with OpenWrt and mt7621 devices? 