See here:
Besides the USB port both devices are virtually identical; so this might help (but there might be modifications needed to get it to work on the DIR-882; so don't try anything unless you know what you're doing and can recover from a faulty flash).
Because someone needs to send in a patch or create a pull request, which hasn't happened yet.
The github repository linked above is a good start.
Build the image for The DIR-878, flash it, report back if it is working.
Once that is done, it only needs someone to invest some time in sending in the patch or create a pull request.
I build an image from OpenWRT master for DIR-882 A1 by adapting the patch for DIR-878 and it seems to work well enough for a WiFi AP. Didn't test USB yet but that is on the to do list as I want to use the router with a LTE USB Dongle as moble broadband gateway.
Adaptation was simple enough as I only replaced pattern DIR-878 with DIR-882 so I would assume the DIR-878 image would probably work also, just reporting different hardware type.
Great work @Lucky1 and thanks.
It seems the only difference between both is the 882 having USB 3 and the 878 having no USB really. That means you could share a common DTS (.dtsi) etc.
Quick test with USB storage with VFAT USB stick proved both USB-2 and USB-3 work on the DIR-882 as is.
Sadly both 2,4G & 5G the WiFi are rather unstable as after a while (usually less than 30 minutes) dmesg gets flooded with "mt7615e: Message X timeout" and WiFi goes unresponsive.
I need to find some time to investigate the WiFi issue bit more thoroughly.
To me it does bit resembled the [MCU issue] (https://github.com/openwrt/mt76/issues/142) mt76-driver had on DIR-860L.
Thanks to holidays there is bit more time to play with the DIR-882.
Latest mt76 driver (master) solves the issue with MCU timeouts and the AP has been running stable for more than 24 hours.
Last major issue for me is poor tx performance and I see same issue has already been reported to mt76 repo. https://github.com/openwrt/mt76/issues/327
For me the difference between ideal vs. non-idea conditions is rather small,
it enough to have even slightly obstructed line of sight between AP and client to cause tx rate to drop.
This is what it looks to me without clear line of sight between laptop and AP in the same room using 80Mhz bandwidth.
root@zenbook:~# iperf3 -R -c 192.168.254.7
Connecting to host 192.168.254.7, port 5201
Reverse mode, remote host 192.168.254.7 is sending
[ 4] local 192.168.254.60 port 53200 connected to 192.168.254.7 port 5201
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 60.1 MBytes 504 Mbits/sec
[ 4] 1.00-2.00 sec 58.2 MBytes 488 Mbits/sec
[ 4] 2.00-3.00 sec 58.4 MBytes 490 Mbits/sec
[ 4] 3.00-4.00 sec 59.6 MBytes 500 Mbits/sec
[ 4] 4.00-5.00 sec 58.3 MBytes 489 Mbits/sec
[ 4] 5.00-6.00 sec 59.6 MBytes 500 Mbits/sec
[ 4] 6.00-7.00 sec 59.7 MBytes 501 Mbits/sec
[ 4] 7.00-8.00 sec 59.1 MBytes 496 Mbits/sec
[ 4] 8.00-9.00 sec 58.2 MBytes 488 Mbits/sec
[ 4] 9.00-10.00 sec 58.9 MBytes 494 Mbits/sec
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 593 MBytes 498 Mbits/sec 0 sender
[ 4] 0.00-10.00 sec 590 MBytes 495 Mbits/sec receiver
iperf Done.
root@zenbook:~# iperf3 -c 192.168.254.7
Connecting to host 192.168.254.7, port 5201
[ 4] local 192.168.254.60 port 53224 connected to 192.168.254.7 port 5201
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.00 sec 10.6 MBytes 89.2 Mbits/sec 0 238 KBytes
[ 4] 1.00-2.00 sec 8.95 MBytes 75.1 Mbits/sec 0 223 KBytes
[ 4] 2.00-3.00 sec 12.7 MBytes 107 Mbits/sec 0 263 KBytes
[ 4] 3.00-4.00 sec 10.3 MBytes 86.6 Mbits/sec 0 235 KBytes
[ 4] 4.00-5.00 sec 1.24 MBytes 10.4 Mbits/sec 48 26.9 KBytes
[ 4] 5.00-6.00 sec 19.7 MBytes 165 Mbits/sec 2 280 KBytes
[ 4] 6.00-7.00 sec 18.5 MBytes 155 Mbits/sec 0 254 KBytes
[ 4] 7.00-8.00 sec 13.7 MBytes 115 Mbits/sec 0 240 KBytes
[ 4] 8.00-9.00 sec 11.7 MBytes 98.5 Mbits/sec 0 243 KBytes
[ 4] 9.00-10.00 sec 6.84 MBytes 57.4 Mbits/sec 80 238 KBytes
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 114 MBytes 95.9 Mbits/sec 130 sender
[ 4] 0.00-10.00 sec 110 MBytes 92.7 Mbits/sec receiver
With clear line of sight between laptop and AP, same room and same distance tx is much better
root@zenbook:~# iperf3 -c 192.168.255.7
Connecting to host 192.168.255.7, port 5201
[ 4] local 192.168.255.60 port 53270 connected to 192.168.255.7 port 5201
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.00 sec 41.7 MBytes 350 Mbits/sec 0 269 KBytes
[ 4] 1.00-2.00 sec 36.2 MBytes 304 Mbits/sec 0 300 KBytes
[ 4] 2.00-3.00 sec 41.7 MBytes 350 Mbits/sec 0 334 KBytes
[ 4] 3.00-4.00 sec 41.1 MBytes 345 Mbits/sec 0 320 KBytes
[ 4] 4.00-5.00 sec 44.0 MBytes 369 Mbits/sec 0 320 KBytes
[ 4] 5.00-6.00 sec 45.5 MBytes 382 Mbits/sec 0 322 KBytes
[ 4] 6.00-7.00 sec 45.1 MBytes 378 Mbits/sec 0 322 KBytes
[ 4] 7.00-8.00 sec 46.5 MBytes 390 Mbits/sec 0 328 KBytes
[ 4] 8.00-9.00 sec 38.6 MBytes 324 Mbits/sec 0 325 KBytes
[ 4] 9.00-10.00 sec 49.9 MBytes 419 Mbits/sec 0 322 KBytes
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 430 MBytes 361 Mbits/sec 0 sender
[ 4] 0.00-10.00 sec 427 MBytes 358 Mbits/sec receiver
Same server and client can reach +450Mbps rx and tx with Netgear R7000 running DD-WRT without direct line of sight. I'm using Intel 9260 on the Ubuntu 18.04.3 laptop as client and ubuntu 18.04.3 as server with gigabit Ethernet.
That's great to hear. I have backported the DIR-878 patch to 19.07 but it's a but hackish. Bumped the mt76 driver as well. Will be switching it with my RT-AC57U as main router soon.
I am new to here, recently replaced my MW4530R with DIR882 and installed padavan hanwckf. I am not quite familiar with this fw at all. And I need mwan, 80211r on DIR882 which is not available on padavan hanwckf.
By any chance OpenWrt can support DIR882 soon? What are the road blocks? Where can see the progress?
@Lucky1 added support, see this thread. He also has built images based on master, since that's where devices get support first. Since 19.07 is right around the corner it's very unlikely it will see support for the DIR-878.
If you'd like to compile yourself, his pull request is here.
Edit: @ikkisunshine - to clarify: the DIR-878 and DIR-882 are basically the same hardware except for the latter having a USB 3 port. I think there was someone running a slightly modified DIR-878 build on his DIR-882 (for the USB port), a search on the forum should turn that up. If you want to use the USB port you should add it to the DTS, I believe.
@Borromini, Thank you so much. I found the thread and downloaded source codes from GitHub, after several days learning I am now compiling the OpenWrt FW now. I don't need the USB 3 at the moment, therefore I am good with DIR-878 FW. Thanks again!
@Borromini, I installed an Ubuntu and git clone from the repository, I followed the steps in readme, and run make V=s but the firmware I finally made not working. It not booting up at all. I have to roll back to Padavan from breed console. Any clue what I did wrong?
Use the binaries then (my first link).
Few more days running the DIR-882 with almost the latest mt76 drvier and it seems the MCU timeouts still appear.
Fri Jan 3 13:26:35 2020 kern.err kernel: [68574.682275] mt7615e 0000:01:00.0: Message 73 (seq 8) timeout
Fri Jan 3 13:27:13 2020 kern.err kernel: [68613.082522] mt7615e 0000:01:00.0: Message 73 (seq 9) timeout
This time the AP is not totally dead as only the 2,4G radio is rendered useless and 5GHz AC radio keeps on working as well as before, the only major gripe being slow tx speeds.
@GaryTTirn I see you've been keeping your fork with these DIR-882 changes up to date. Has there been any improvement in stability or performance since your last post above in January?
I've now been running my 3 DIR-882As for 21 to 23 days with the latest build with full wpad.
Two of these are configured as plain WiFI APs in one location and third is acting as WiFi AP and broadband router in a remote location. About dozen WiFi clients in both locations, mostly stationary and only few mobile devices.
No major issues see, all devices have ieee80211r, ieee80211v and ieee80211k configured.
I did change GTK Rekey interval to one day (86400 seconds) as it seemed to improve WiFi stability and in my case security impact is negligible. 160MHz channel on AC seems to come up but the client is unable to connect, but that's about the only remaining issue for me. With 80Mhz channel AC works just fine.
Under optimal rather optimal conditions I get 350-500Mbps downlink and 500-600Mbps uplink bandwidth when tested with iperf.
I was getting somewhat lower numbers before and to improve performance I've been running with this affinity patch.
I actually need to rebase my fork to the latest master soonish as an improved padding recipe was added and DIR-878 A1 support was finally merged.
Thanks for the update. Great to hear it's working well.
I'm repeating the same test I did back in December, same devices and placement.
I'm getting good signal in that test arrangement (VHT-MCS 9, VHT-NSS 2, Short GI for both TX/RX) and signal is not as badly affected by even slightly obstructed line of sight between AP and client as it used to be.
kari@zenbook:~$ iperf3 -R -c 192.168.254.7
Connecting to host 192.168.254.7, port 5201
Reverse mode, remote host 192.168.254.7 is sending
[ 4] local 192.168.254.21 port 42526 connected to 192.168.254.7 port 5201
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 42.9 MBytes 360 Mbits/sec
[ 4] 1.00-2.00 sec 44.9 MBytes 376 Mbits/sec
[ 4] 2.00-3.00 sec 50.8 MBytes 426 Mbits/sec
[ 4] 3.00-4.00 sec 56.2 MBytes 472 Mbits/sec
[ 4] 4.00-5.00 sec 56.5 MBytes 474 Mbits/sec
[ 4] 5.00-6.00 sec 55.1 MBytes 462 Mbits/sec
[ 4] 6.00-7.00 sec 37.5 MBytes 315 Mbits/sec
[ 4] 7.00-8.00 sec 56.0 MBytes 470 Mbits/sec
[ 4] 8.00-9.00 sec 56.3 MBytes 472 Mbits/sec
[ 4] 9.00-10.00 sec 55.4 MBytes 465 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 521 MBytes 437 Mbits/sec 111 sender
[ 4] 0.00-10.00 sec 512 MBytes 429 Mbits/sec receiver
kari@zenbook:~$ iperf3 -c 192.168.254.7
Connecting to host 192.168.254.7, port 5201
[ 4] local 192.168.254.21 port 42688 connected to 192.168.254.7 port 5201
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.00 sec 61.9 MBytes 519 Mbits/sec 0 913 KBytes
[ 4] 1.00-2.00 sec 66.9 MBytes 561 Mbits/sec 0 1.25 MBytes
[ 4] 2.00-3.00 sec 66.4 MBytes 557 Mbits/sec 0 979 KBytes
[ 4] 3.00-4.00 sec 67.7 MBytes 568 Mbits/sec 0 1.19 MBytes
[ 4] 4.00-5.00 sec 65.4 MBytes 548 Mbits/sec 0 1.15 MBytes
[ 4] 5.00-6.00 sec 66.2 MBytes 556 Mbits/sec 0 1.12 MBytes
[ 4] 6.00-7.00 sec 67.0 MBytes 562 Mbits/sec 0 1.24 MBytes
[ 4] 7.00-8.00 sec 67.3 MBytes 564 Mbits/sec 0 1.47 MBytes
[ 4] 8.00-9.00 sec 65.4 MBytes 549 Mbits/sec 0 1.20 MBytes
[ 4] 9.00-10.00 sec 70.0 MBytes 587 Mbits/sec 0 1.19 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 664 MBytes 557 Mbits/sec 0 sender
[ 4] 0.00-10.00 sec 661 MBytes 554 Mbits/sec receiver
I don't see frequent disconnects from the stationary clients according to the logs and of course having ieee80211r configured on the APs and most mobile clients being recent enough to take advantage of that so handovers between different APs and bands seem to be quick enough not to be noticeable.
I got this up and running on a dir-2660-a1 with trivial modifications to adapt
So definitely looks like dir-1960 and dir-2660 at least can use a common dts.
