Add support for D-Link COVR-X1860

I changed my network setup a fair bit today (added an EdgeRouter X and made both of the D-Links dumb APs instead of having one of them be the router as well) which was when I noticed something: the ethernet and internet interfaces both have the same MAC address.

This does not seem to be common practice for other devices and I wonder if this may have caused my random ARP reply losses.

Is this intentional and if so, why? Does the original FW do this as well or is there another MAC address in the config/factory partition that we should assign to one of the interfaces instead?

I checked my device (MAC on label xx:xx:xx:xx:xx:D6), there I have the same MAC handling as you described in OpenWrt:
LAN MAC: xx:xx:xx:xx:xx:D6
WAN MAC: xx:xx:xx:xx:xx:D6
2.4G MAC: xx:xx:xx:xx:xx:D7
5G MAC: xx:xx:xx:xx:xx:D8

I flashed OEM COVR-X1860_fw_reva_102b01_ALL_multi_20230630 and hat a look, there the siuation is different:
LAN MAC: xx:xx:xx:xx:xx:D6
WAN MAC: xx:xx:xx:xx:xx:D9
2.4G MAC: xx:xx:xx:xx:xx:D7
5G MAC: xx:xx:xx:xx:xx:D8

1 Like

Thanks for checking! So the WAN MAC address should really be LAN MAC address plus 3? Should we change the patches accordingly?

As far as I understood, target/linux/ramips/mt7621/base-files/etc/board.d/02_network must be changed from

		label_mac=$(mtd_get_mac_ascii config2 factory_mac)


		label_mac=$(mtd_get_mac_ascii config2 factory_mac)
		wan_mac=$(macaddr_add "$label_mac" 3)

Maybe @s_2 can have a look at it?

1 Like

Is there an improvement if you change the WAN MAC manually in OpenWrt?

I've done so and I don't see any obvious issues anymore, but I've also changed the setup a bit. Changing it back would involve annoying my wife so I'd like to refrain from that. :smiley:

@Ultrazauberer: You ran into the same issue, or so it seems. Could you give this a shot?

I will check it on my network. But at the moment I haven't any strange issues. The only one I had was the dropping connection after wifi roaming. I changed the encryption to WPA2 and my issues are gone.

What are the results of dropping the ARP requests? Are your clients dropping the internet connection because they are confused of the same MACs?

I can describe my network and guess why I'm not having these issues:

In the basement there is my 48port managed switch. There I hooked up a VDSL2 Router in Modem mode. The Port of the basement switch where the VDSL2 Modem is connected has only tagged VLAN7.
On the first floor I have the COVR device with tagged VLAN7 and untagged traffic on the Ethernet port. On the basement side the Port has also VLAN7 (for internet traffic) and untagged traffic for the local network.

So I'm using one physical port of the COVR device with different VLANs. I know it will split my Gbit/s connection in half but I only have 100Mbit/s connection to the internet.

Maybe that's why I didn't face your issues?

Alright, your setup is clearly on a different level than mine :sweat_smile:

I had an ISP-provided fiber-to-Ethernet converter connected to one of the COVR units, which served as the router (VLAN tag 7 + PPPoE) and an AP, then a switch connected to this to which I had connected the other AP as well as two computers. The second AP then had another computer connected to its Ethernet port.

Whenever roaming between the APs happened, there was a considerable chance that the roaming device would no longer receive any ARP replies after roaming. The replies would be generated, as could be seen in a tcpdump generated on the respective AP, but the device would never receive it (also confirmed via tcpdump/Wireshark).

There's a bug report on GitHub about ARP replies not making it to the device anymore related to WiFi devices and setups using VLANs. I wanted to rule that out so I got an ER-X to replace the one COVR as the router.

While I was setting up this new setup, I noticed the duplicate MAC addresses and fixed them. So now I'm not sure what actually fixed the issue - the ER-X doing the VLAN tagging instead of the AP, or the duplicate MAC addresses fix.

1 Like

Has anyone here actually been able to achieve an advertised WiFi speed of 1800 Mbit/s? The highest that I can get my AP to report when set to AX is 1020 Mbit/s, with 866 Mbit/s on the 5 GHz band and 243 on the 2.4 GHz band.

Or am I misunderstanding the marketing claims? :smiley:

I'm actually nowhere near your throughput! I don't expect it'll ever hit the marketing numbers though.

I've got a simple setup (both COVR-X1860):

  • Main router
  • Dumb AP backhaul to main router using WDS over 5GHz using AC @ 80Mhz

Running iperf3 directly on the main router and dumb AP, I see peaks of ~327Mbits/s in one direction, and ~250Mbits/s in the other. These routers have literal line-of-sight and are about 8 meters apart, though it does have to go through a glass window.....

AX was noticeably slower for me, and had less stable throughput! Can you share your configs? I'd like to have 866Mbits over 5GHz!

Oh no, I'm not even close to the reported data rates either. My clients report the connection as having a link speed of 866 Mbit/s, but an iperf3 test from a WiFi 6-capable laptop to a wired PC shows also around 330 Mbit/s.

My point was that I can't even get the AP to report the advertised link speed of 1.8 Gbit/s, not that it would ever reach that speed in a real-world scenario.

is is configured as pure access point?
Or is routing, NAT and firewall active as well?

Pure, dumb AP. All my routing, NATing and firewalling is done by an EdgeRouter X.

my D-Link dir 2660 with OpenWRT 22 (also MT7621 CPU, 4x4 MIMO, with the older Wifi AC and external antennas) when as pure AP used to get close to 550Mbit AC with certain 2x2 AC devices and around 380MBit when also required to route/NAT/FW (on disabled HW offload).
(80Mhz, 5Ghz, channel 44, no other tuning)

My MR90X with Mediathek AX Wifi (stronger CPU and extensive antenna posing) can sometimes get close to 950mbit/s on certain 2x2 AX clients close by, on non-blocked air (again 80Mhz, 5Ghz, channel 44, no other tuning).

From my perspective the CPU should not yet be a blocking factor in your case. And there should be no secret buttons to miss.

300mbit/s looks like the client might be at least a 2x2 design. I would say then it is could be the integrated smaller antenna design of the COVR or a limitation of the client or crowded air or combination.

Alright, the above post made me dig into this a bit deeper. I've tried a few clients and was able to get a maximum throughput of about 620 Mbit/s in the receiving direction on the 866 Mbit/s link speed. I didn't change any configuration for that but rather adjusted the iperf3 parameters: -Z enables a zero-copy mode which is evidently much easier on the CPU, and -R reverses the direction of the test, as usually iperf3 tests the speed from the client to the server, but I tend to run the server on the wired device.

These results are good enough for me and I'll stick with this. :slight_smile:

Also, an update on my ARP reply loss topic: This did happen again so I played with the configuration a fair bit more. I tried accepting gratuitous ARP packets (no effect), enabling promiscuous mode (no effect), enabling Multicast to Unicast for all WiFi networks (no effect). Finally I ended up setting up a separate WiFi network which has 802.11r Fast Transition disabled. Since then, I've had no more sudden reply loss on my Android phone. I will keep an eye on this and hope that this is the final solution to my problem.


My connection speed is jumping between 780Mbit/s and lower on the 5Ghz band. I didn't run into speed issues so I didn't verify with iperf.

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:

1 Like