Some of the Gluon devs have commit rights and you could ask them to review and merge your commits, this would speed up the process of getting support for these into Gluon. Especially the covr-x186x.
I just bought two of them at Mediamarkt. They are a great alternative for the dap-x1860 which apparently just went out of stock at the same vendor.
It's also a great timing, the covr-x186x just dropped from 100€ to 40€ at the start of June (even before the sale at Mediamarkt). So this is probably an EoL-sale (last stock they have available) like they did for the dap-x1860, we could take advantage of that if we can provide support now.
Hey @s_2 - amazing work! I'm having troubling building the covrx1860_sgeimage branch, but I suspect it might be me - I had built your covrx1860_master branch previously, but I can't get that to work now either! Just in case it isn't me, I've attached the build failure here: https://pastebin.com/jYS6yarw
I should have mentioned that the covrx1860_sgeimage branch assumes a bump of firmware-utils to a version containing the patch I had sent to the mailing list, which needs to be done locally (as it's not in public OpenWrt yet), but your problem is not even related to that, even the toolchain build seems to fail.
You could try make distclean (or even make dirclean if it still doesn't work), but it will take some time to rebuild everything.
Added default-state for orange LED on boot (filling the short LED-off gap between bootloader and kernel controlling the LEDs), dropped unneeded pinmux settings, rebased _sgeimage branch.
I am still a little annoyed by mt76 spawning LEDs for phy0 and phy1 that can be configured by the user in LuCI, although there are no LEDs connected to these pins. This affects other devices as well though.
It seems they can only be disabled completely (c.f. issue #788), the dts attribute led-sources only specifies a GPIO pin, but does not seem to allow completely disabling them (c.f. mac802.11c in mt76).
Now looking over the dts again, I'm still bothered by the power vs. status LED naming, as far as I recall the names should actually be distinct for each LED position in the device case, so if there's a multi-color LED, it should use the same name, with different colors. So this device should have them all named the same way. But use power or status then? Other devices with red/green LEDs in a single position also use power and status (I even used this scheme myself with some D-Link devices ).
Any final suggestions on how to name them here?
build your images with this patch https://github.com/freifunk-gluon/gluon/pull/2905 if you require Meshing between ath10k and mtk. Yes, this issue hasn't been fixed, yet.
I was wrong, this issue is fixed in master. The patch is only required for OpenWrt 22. My bad
Hello everyone!
First of all, thanks for the amazing effort to port this device to OpenWRT.
I am a user of the Covrx 1860 but I find it very limited with the stock firmware, so reading this forum, I decided to buy a spare one so I can test it without breaking my working network. Unfortunately, I am an absolute noob to OpenWRT with too many questions. I will be very grateful if you can answer some of them:
What is the current status on the port? Is it an unofficial port or would it be official at some point?.
Given that the COVRX 1860 is a mesh-capable device, how does it work with OpenWRT? Do you have to flash it in both of the devices and configure them individually?.
Does Mesh + VLAN work fine with this device?.
I have got Roland's built images, but I have no idea where to start and what to flash. If you now any resource that helps me start with the process, please let me know.
Sorry if the questions are too basic.
Thanks in advance for your time!.
the current status is that a patch was sent to the mailing list for adding the image encryption tool.
Since this goes to a separate repository, it needs to merged first so that the actual device support patch can then refer to that commit.
The stock firmware implements lots of proprietary communication between the devices, to achieve several functionalities that would go along with the "mesh" buzzword these days.
OpenWrt supports 802.11s as a standardized way of meshing between devices, but this does not cover all aspects of what the vendor firmware supports.
There is stuff like 802.11k, v and r, but there is no userspace service available by default that implements all of the same features in OpenWrt in a ready-to-use way.
I think the main issue is that for the core user base of OpenWrt, this scenario (using wifi to forward wifi traffic) is not the typical use case, since most people would just run network cables through their homes and use these devices as Access Points
From Roland's images, just take the squashfs-factory.bin and upload it (just like a regular D-Link firmware update) via the device's webinterface.
Hello @LateAsUsual ,
I cannot answer all of your questions, additionally to the response from @s_2, that's what I can tell you so far:
The images I built are no official images. Support for COVR-X1860 is not yet included in OpenWrt. I assume, first a patch for creating the images (see Add support for D-Link COVR-X1860 - #39 by s_2) must be merged, afterwards a Merge Request for supporting the deivce can be created.
I didn't configure mesh manually until now, just used it for Freifunkt builds, there mesh is working. A starting point may be https://openwrt.org/docs/guide-user/network/wifi/mesh/start. But this will require OpenWrt on all your devices.
Regarding the images, you should be able to flash openwrt-ramips-mt7621-dlink_covr-x1860-a1-squashfs-factory.bin via the web interface of the D-Link firmware. Alternatively, you can flash openwrt-ramips-mt7621-dlink_covr-x1860-a1-squashfs-recovery.bin in recovery mode of the device.
Recovery mode can be entered by pressing the reset button while powering on the device. The recovery web interface can be accessed via http://192.168.0.1. You have to set your computers IP manually to for example 192.168.0.10/255.255.255.0. A Chromium based browser must be used in this case to flash the image successfully.
Additional remark: The images I built may not contain all required packages which are required to set up a mesh network. They must be installed in the OpenWrt web interface after flashing the image.
@s_2 I understand what you say about the typical scenario, however it is not my case as I am not a homeowner and allowed modifications to the house are very limited, so mesh + vlan is kind of what I am looking for in this device. Do you think 802.11s would be good enough for this case? (I looked it up, but I am not 100% sure to understand it).
@RolandoMagico understood. Then it is safe to assume that your images are a pre-release for testing / tinkering purposes, right?. I will give it a try once the COVR-X1860 is delivered. Thanks for the instructions.
Does any of you know what is the average elapse time between our current situation and the official inclusion of the device in OpenWRT? I tried to extrapolate the information from other posts in the forum without success.
The time until official inclusion depends on the OpenWrt maintainers. As soon as all merge requests are included, there will be a snapshot (nightly build if I'm not wrong) supporting the device.
And then it depends on the release planning to get the device supported in the next official OpenWrt release.
Not sure who in this forum can provide more detailled information regarding the timelines.
).
