Add support for D-Link COVR-X1860

wait, so they waste unused RF chains just for marketing purposes? I see that the PCB of DIR-2660 allows for multiple populations though, e.g. there are 8 antenna connector footprints, but only 4 populated.
Maybe Mediatek just sell different versions of their wifi chipsets in the same package, so the footprint would remain pin-compatible regardless of the number of spatial streams / antennas supported, I haven't looked so closely at what's actually written on the chips though.

Migrating back to slightly older OpenSSL was less of an issue than expected, also fixed warnings about fread() output being unused (i.e. implemented proper error handling if input file is too short).

Updated branch dlink-sge-image_2k23, also including key for DIR-2150 as mentioned in a current PR for that device.

It is now part of my local build system, next step: rebase some old PR for COVR-C1200 to master for final testing, also COVR-X1860 of course. This should now allow us to build images that are accepted by the OEM webinterface, if all goes well, I will send a PR for this tool to the mailing list :slightly_smiling_face:

Finally, tests with COVR-C1200 and COVR-X1860 were successful, the latter was quite annoying though in terms of trying to login to the web interface... Using Chromium in Incognito mode eventually worked, even Firefox didn't do it for me anymore, kept getting the "invalid password" message.

Curiously, the whole webinterface is a static web application that uses HNAP to login and configure the router, it seems the implementation of the challenge/response login stuff might not be working correctly?
It seems kind of ironic to put so much effort in getting rid of the bootloader recovery for flashing, just to treat the user to a different set of browser-induced flashing troubles instead :joy:

Added a new branch, not yet squashed:

But first, we need the tool in firmware-utils, I will send a patch to the mailing list :slightly_smiling_face:
@Lucky1 can I add your Tested-By to the commit message for the patch?

yes the DIR-878 & the DIR-1960 are the same both ac3200 at lest the ones I have
but the 867 had some transistors removed
that's not to say that there are all like that tho
but as they all use the same PCB just with different loading had to same
both of mine do have 4 steams on 2.4 & 5G in it's factory config
I'm making the presumption that the 867 has only 3's in there not 4's
once I'm happy my Linux pc is set-up & working I'll test & note etc

I don't think it's an absolute requirement to test further if this is inconvenient to you at the moment, I just wanted to offer adding your name to the commit, since you've helped a lot in working on this series of devices. Just let me know whether I shall wait for your test, or send a patch to the list already? A few days won't make any difference here, so feel free to take you time, e.g. over the weekend.

I'm having another look at C1200 / P2500, time to replace the gzip-signature (which is actually just crc32 as it turned out) with a build recipe, and get rid of the Python script.

all good here now I'm more up to date now
I have tested the current version on the current master
on the DIR-867-878-882-A1's and all work fine from web install to openwrt :slight_smile:
can add away only tested in encode mode all works great :slight_smile:

1 Like

1 Like

For those located in Germany:
MediaMarkt / Saturn currently offer 19% off until sunday, making the total price for the pack of two devices € 33,61 with shipping included.


I just noticed your work here. awesome!

maybe you get in contact with me and/or the devs from the Gluon project over at their IRC, if you're are interested.

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.

Greetings from Freifunk Aachen

1 Like

For the ones who use this device already with Freifunk: Is still active using openwrt 22.03?

Maybe related to MT7621 incompatibility with mesh, I currently face bad performance in downloads meshing against a FRITZ!Box 4040

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:

Can you share a pre-built factory image?

Hi @dom1 , if you don't need an up to date image, I built one two weeks ago:

1 Like

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 :innocent: ).
Any final suggestions on how to name them here?

Status as name for the LED makes more sense in my opinion. That’s also what DLink uses:

1 Like

Renamed white led to status, renamed factory-webflash to factory and factory-recovery to just recovery, as it was suggested in the old PR for DIR-842.

If somebody is interested in testing: I built a basic image including luci against the current OpenWrt main brauch:

Hi @s_2 sorry about the delay.

I do indeed have a dump of the DIR-853 (A3) as well as the DIR-1360. I will send them to you via PM.

build your images with this patch 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


I've successfully flashed @RolandoMagico's factory image linked above onto a spare COVR-X1860 and it works perfectly!

It's already way more stable than the stock firmware. Thank you all, and especially @s_2 for the porting effort!

For others following along: I noticed a meaningful throughput difference using ax on the COVR-X1860 after following this suggestion: 802.11ax worse than 802.11ac with mt76 driver? - #50 by anon11662642