Add support for D-Link COVR-X1860

Does anyone have a decrypted stock firmware?

Hello everyone,
As the patch for creating the encrypted firmware images (see Add support for D-Link COVR-X1860 - #39 by s_2) is still open, one question from my side:
Would it make sense to already create a pull request for supporting this device in OpenWrt without support for flashing via stock/recovery web interface? In this case the switch to OpenWrt would only be possible using a serial interface and the initramfs image with the official OpenWrt builds.

As soon as the patch for creating the stock/recovery images is accepted, another pull request would be required to add the additional images for this device.

There are multiple stock/recovery images linked in this thread, they can also be used for switching to an official OpenWrt image (Probably only if the memory layout doesn’t change).

Or are there other risks (for example bricked devices because of the more complicated switching to OpenWrt using the serial interface)?

In the worst case, one could still switch back to OEM firmware or one of the images in this thread using the recovery web interface.

wouldn't be the 1st device requiring serial for openwrt flashing.

Silly question, but couldn't the firmware-utils patch be submitted as a patch file as part of the device support PR? It wouldn't be the first patch for firmware-utils: https://github.com/openwrt/openwrt/blob/main/tools/firmware-utils/patches/001-add-sifiveu-guid-types.patch

1 Like

That's very curious to see this actually got merged :joy:
So far I've only seen this done for backports of new devices to old branches, especially when the latest release branch was forked only recently.

I would have expected the relocation of firmware-utils outside of the main repo was intended to also reduce the complexity of review required for a single device PR to be merged into OpernWrt, but not the other way round with firmware-utils being even more difficult to get accepted... :innocent:

1 Like

We have a merge in firmware-utils :blush:
https://git.openwrt.org/?p=project/firmware-utils.git;a=commit;h=ba5bc4e1ae9d3e7b41d3bed39ce505670dc95078

The bump PR is at https://github.com/openwrt/openwrt/pull/13861

I won't be near my main development machine over the weekend, so I could open the PR for COVR-X1860 by the middle of next week.
@RolandoMagico Feel free to do so in the meantime, if you can find the time.
Your knowledge regarding these devices is probably way more recent than mine now :innocent:

3 Likes

Done: https://github.com/openwrt/openwrt/pull/13865

I also included the changes from Add support for D-Link COVR-X1860 - #264 by RolandoMagico

Can you have a look at it? Hopefully I didn't miss anything

2 Likes

I encountered an issue when installing 'wpa-openssl' or 'wpa-wolfssl'; it didn't work at all until I manually applied this patch.

ubus call system board
{
        "kernel": "5.15.130",
        "hostname": "OpenWrt",
        "system": "MediaTek MT7621 ver:1 eco:3",
        "model": "D-Link COVR-X1860 A1",
        "board_name": "dlink,covr-x1860-a1",
        "rootfs_type": "squashfs",
        "release": {
                "distribution": "OpenWrt",
                "version": "23.05-SNAPSHOT",
                "revision": "r23444-7714fb72be",
                "target": "ramips/mt7621",
                "description": "OpenWrt 23.05-SNAPSHOT r23444-7714fb72be"
        }
}

There is no patch found behind that link, but I would assume installation of the packages failed since this is a snapshot build, resulting in kernel hashes mismatch?

Yes, I am sorry, here is the correct link:
https://github.com/openwrt/openwrt/commit/ed0ad7759c6ff823f3d43c5189cf6c2d59529244

And maybe, it has something to do with the MD5 sum. But as I understand it, they are not longer used anymore in the hostapd_conf_file and bss_conf.

Was there any error message you received when trying to install without the patch? installation was via opkg, or did you include the packages for your custom build via menuconfig?

No, I didn't compile it. I just installed it through opkg. The installation process worked flawlessly, but only activating the mac80211 didn't work.

Curious, though it seems other mt7915 devices should be affected as well then :thinking:

Okay, I will try to reproduce it, maybe it was just a curiosity.
I flashed my Router with the firmware from:
https://dl.riditt.de/openwrt/openwrt-23.05-2023-10-30/targets/ramips/mt7621/

ubus call system board
{
        "kernel": "5.15.130",
        "hostname": "OpenWrt",
        "system": "MediaTek MT7621 ver:1 eco:3",
        "model": "D-Link COVR-X1860 A1",
        "board_name": "dlink,covr-x1860-a1",
        "rootfs_type": "squashfs",
        "release": {
                "distribution": "OpenWrt",
                "version": "23.05-SNAPSHOT",
                "revision": "r23444-7714fb72be",
                "target": "ramips/mt7621",
                "description": "OpenWrt 23.05-SNAPSHOT r23444-7714fb72be"
        }
}

After installing wpad-openssl and my logread without using the patch.

Sat Nov  4 17:27:31 2023 daemon.warn odhcpd[1672]: No default route present, overriding ra_lifetime!
Sat Nov  4 17:27:45 2023 daemon.notice hostapd: Configuration file: /var/run/hostapd-phy0.conf (phy phy0-ap0) --> new PHY
Sat Nov  4 17:27:45 2023 daemon.err hostapd: Line 50: unknown configuration item 'radio_config_id'
Sat Nov  4 17:27:45 2023 daemon.err hostapd: 1 errors found in configuration file '/var/run/hostapd-phy0.conf'
Sat Nov  4 17:27:45 2023 daemon.err hostapd: Failed to set up interface with /var/run/hostapd-phy0.conf
Sat Nov  4 17:27:45 2023 daemon.notice netifd: radio0 (3942): Command failed: ubus call hostapd config_add {"iface":"phy0-ap0", "config":"/var/run/hostapd-phy0.conf"} (Invalid argument)
Sat Nov  4 17:27:45 2023 daemon.notice netifd: radio0 (3942): Usage: ubus [<options>] <command> [arguments...]
Sat Nov  4 17:27:45 2023 daemon.notice netifd: radio0 (3942): Options:
Sat Nov  4 17:27:45 2023 daemon.notice netifd: radio0 (3942):  -s <socket>:             Set the unix domain socket to connect to
Sat Nov  4 17:27:45 2023 daemon.notice netifd: radio0 (3942):  -t <timeout>:            Set the timeout (in seconds) for a command to complete
Sat Nov  4 17:27:45 2023 daemon.notice netifd: radio0 (3942):  -S:                      Use simplified output (for scripts)
Sat Nov  4 17:27:45 2023 daemon.notice netifd: radio0 (3942):  -v:                      More verbose output
Sat Nov  4 17:27:45 2023 daemon.notice netifd: radio0 (3942):  -m <type>:               (for monitor): include a specific message type
Sat Nov  4 17:27:45 2023 daemon.notice netifd: radio0 (3942):                   (can be used more than once)
Sat Nov  4 17:27:45 2023 daemon.notice netifd: radio0 (3942):  -M <r|t>         (for monitor): only capture received or transmitted traffic
Sat Nov  4 17:27:45 2023 daemon.notice netifd: radio0 (3942):
Sat Nov  4 17:27:45 2023 daemon.notice netifd: radio0 (3942): Commands:
Sat Nov  4 17:27:45 2023 daemon.notice netifd: radio0 (3942):  - list [<path>]                  List objects
Sat Nov  4 17:27:45 2023 daemon.notice netifd: radio0 (3942):  - call <path> <method> [<message>]       Call an object method
Sat Nov  4 17:27:45 2023 daemon.notice netifd: radio0 (3942):  - subscribe <path> [<path>...]   Subscribe to object(s) notifications
Sat Nov  4 17:27:45 2023 daemon.notice netifd: radio0 (3942):  - listen [<path>...]                     Listen for events
Sat Nov  4 17:27:45 2023 daemon.notice netifd: radio0 (3942):  - send <type> [<message>]                Send an event
Sat Nov  4 17:27:45 2023 daemon.notice netifd: radio0 (3942):  - wait_for <object> [<object>...]        Wait for multiple objects to appear on ubus
Sat Nov  4 17:27:45 2023 daemon.notice netifd: radio0 (3942):  - monitor                                Monitor ubus traffic
Sat Nov  4 17:27:45 2023 daemon.notice netifd: radio0 (3942):
Sat Nov  4 17:27:45 2023 daemon.notice netifd: radio0 (3942): Device setup failed: HOSTAPD_START_FAILED
Sat Nov  4 17:27:45 2023 daemon.notice netifd: Wireless device 'radio0' set retry=0
Sat Nov  4 17:27:45 2023 daemon.crit netifd: Wireless device 'radio0' setup failed, retry=0
Sat Nov  4 17:27:45 2023 daemon.notice netifd: radio0 (4102): WARNING: Variable 'data' does not exist or is not an array/object
Sat Nov  4 17:27:45 2023 daemon.notice netifd: radio0 (4102): Bug: PHY is undefined for device 'radio0'
Sat Nov  4 17:27:45 2023 daemon.notice netifd: Wireless device 'radio0' is now down

Only deleting line 497 & 498 in /lib/netifd/wireless/mac80211.sh. And now it is working.

Sat Nov  4 17:32:36 2023 daemon.warn odhcpd[1672]: No default route present, overriding ra_lifetime!
Sat Nov  4 17:32:42 2023 daemon.notice hostapd: Configuration file: /var/run/hostapd-phy0.conf (phy phy0-ap0) --> new PHY
Sat Nov  4 17:32:42 2023 kern.info kernel: [  466.195316] br-lan: port 2(phy0-ap0) entered blocking state
Sat Nov  4 17:32:42 2023 kern.info kernel: [  466.200936] br-lan: port 2(phy0-ap0) entered disabled state
Sat Nov  4 17:32:42 2023 kern.info kernel: [  466.207170] device phy0-ap0 entered promiscuous mode
Sat Nov  4 17:32:42 2023 kern.info kernel: [  466.212495] br-lan: port 2(phy0-ap0) entered blocking state
Sat Nov  4 17:32:42 2023 kern.info kernel: [  466.218159] br-lan: port 2(phy0-ap0) entered forwarding state
Sat Nov  4 17:32:42 2023 kern.info kernel: [  466.225273] br-lan: port 2(phy0-ap0) entered disabled state
Sat Nov  4 17:32:43 2023 kern.info kernel: [  466.848558] IPv6: ADDRCONF(NETDEV_CHANGE): phy0-ap0: link becomes ready
Sat Nov  4 17:32:43 2023 kern.info kernel: [  466.855665] br-lan: port 2(phy0-ap0) entered blocking state
Sat Nov  4 17:32:43 2023 kern.info kernel: [  466.861289] br-lan: port 2(phy0-ap0) entered forwarding state
Sat Nov  4 17:32:43 2023 daemon.notice hostapd: phy0-ap0: interface state UNINITIALIZED->ENABLED
Sat Nov  4 17:32:43 2023 daemon.notice hostapd: phy0-ap0: AP-ENABLED
Sat Nov  4 17:32:43 2023 daemon.info dnsmasq[1]: read /etc/hosts - 12 names
Sat Nov  4 17:32:43 2023 daemon.info dnsmasq[1]: read /tmp/hosts/dhcp.cfg01411c - 0 names
Sat Nov  4 17:32:44 2023 daemon.notice netifd: Wireless device 'radio0' is now up
Sat Nov  4 17:32:44 2023 daemon.notice netifd: Network device 'phy0-ap0' link is up
Sat Nov  4 17:32:45 2023 daemon.warn odhcpd[1672]: No default route present, overriding ra_lifetime!
Sat Nov  4 17:35:12 2023 kern.info kernel: [  616.326111] device phy0-ap0 left promiscuous mode
Sat Nov  4 17:35:12 2023 kern.info kernel: [  616.331139] br-lan: port 2(phy0-ap0) entered disabled state
Sat Nov  4 17:35:12 2023 daemon.notice netifd: radio0 (5410): WARNING: Variable 'data' does not exist or is not an array/object
Sat Nov  4 17:35:12 2023 daemon.notice netifd: radio0 (5410): Bug: PHY is undefined for device 'radio0'
Sat Nov  4 17:35:12 2023 daemon.notice netifd: Wireless device 'radio0' is now down
Sat Nov  4 17:35:15 2023 daemon.info dnsmasq[1]: read /etc/hosts - 12 names
Sat Nov  4 17:35:15 2023 daemon.info dnsmasq[1]: read /tmp/hosts/dhcp.cfg01411c - 0 names
Sat Nov  4 17:35:16 2023 daemon.warn odhcpd[1672]: No default route present, overriding ra_lifetime!
Sat Nov  4 17:35:29 2023 daemon.notice netifd: Wireless device 'radio0' is now up
Sat Nov  4 17:35:29 2023 daemon.notice netifd: Network device 'phy0-ap0' link is up
Sat Nov  4 17:35:29 2023 kern.info kernel: [  633.333033] br-lan: port 2(phy0-ap0) entered blocking state
Sat Nov  4 17:35:29 2023 kern.info kernel: [  633.338729] br-lan: port 2(phy0-ap0) entered disabled state
Sat Nov  4 17:35:29 2023 kern.info kernel: [  633.344964] device phy0-ap0 entered promiscuous mode
Sat Nov  4 17:35:29 2023 kern.info kernel: [  633.350373] br-lan: port 2(phy0-ap0) entered blocking state
Sat Nov  4 17:35:29 2023 kern.info kernel: [  633.356062] br-lan: port 2(phy0-ap0) entered forwarding state

I added these lines back, and the same error occurred. I can do this the whole day.

497	-	radio_md5sum=$(md5sum $hostapd_conf_file | cut -d" " -f1)
498	-	echo "radio_config_id=${radio_md5sum}" >> $hostapd_conf_file

It looks like my build job ended up using an older commit as I've force-pushed the branch a couple of times instead of merging it to update it with the upstream version, which caused the git pull to fail, but the package update to still work.

I've now fixed this, so tonight's 23.05 build should be in-sync again. This should fix the issue you're encountering.

Thanks alot i will try it tomorrow.

Hi everyone!
Happy to see that the page is alive & kicking.

Given that time has passed and the official inclusion of this device is closer than it was before, I would like to anticipate the need:

My nodes are fully configured and working pretty fine with the snapshot build that @RolandoMagico provided (thanks again, buddy). However, I assume that I will have to reflash the firmware once the device become officially supported.

Therefore, I want to make sure what the right steps are.
Would it be as simple as taking a backup of the configuration, flashing the official firmware and restoring the configuration in each device?.

If anyone has experience with it, any input would be highly appreciated.
Thanks in advance!

As soon as the official snapshot images would become available, you can simply sysupgrade via LuCI, and check the option to keep settings.

Do you require any special packages for the mesh to work? This might be an issue (even with the option to keep packages, i.e. reinstall them automatically after flashing) since they could not install via opkg when there is no internet connection possible without these packages.
But for the normal use cases, this should not be an issue.

Snapshots don't come with LuCI by default, not sure if this will be installed automatically as well when it had been contained in the previous image, rather than installed individually via opkg :thinking: