That's very curious to see this actually got merged 
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... 
We have a merge in firmware-utils 
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
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
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 
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
Hi @s_2 !
Indeed I need extra packages like batman, LuCI and some others, therefore, I would like to know the right steps to make it work.
Would taking a backup, flashing the clean firmware, installing the packages and restoring the backup work?.
Cheers!
Ideally, all OpenWrt packages would store their configuration only within UCI to be portable, but I'm not sure about all of the packages, e.g. batman (at least with Freifunk, many communities use a VPN uplink and have the router generate a randomized key on firstboot, which is not stored in UCI).
So I guess most of the config should work, but there might be issues depending on certain packages (not related to COVR-X1860 device support).
This should be addresses with the maintainers of any packages that don't survive a sysupgrade, since you will need a working upgrade path for future releases / security fixes. If packages are required for the initial internet connection (to download others), they should be built into your sysupgrade image, e.g. using the OpenWrt firmware selector.
The pull request adding support for the device was merged: https://github.com/openwrt/openwrt/pull/13865 
I have question for fast roaming, I can say here work bad... Or I do something wrong. Long, or lose connection. .. Can anyone help configure that use wolf wpad.