OpenWrt Support for Asus RT-AC88U

With this version I was not able to establish a wireless connection, even as open network.

Extracted from system.log:
Mon Feb 15 15:34:46 2021 user.info kernel: [ 8.837775] kmodloader: loading

kernel modules from /etc/modules.d/*
Mon Feb 15 15:34:46 2021 kern.info kernel: [    8.847015] ip6_tables: (C) 2000-2006 Netfilter Core Team
Mon Feb 15 15:34:46 2021 user.info kernel: [    8.852171] urngd: v1.0.2 started.
Mon Feb 15 15:34:46 2021 kern.info kernel: [    8.856951] Loading modules backported from Linux version v4.19.161-0-gdaefdc9eb24b
Mon Feb 15 15:34:46 2021 kern.info kernel: [    8.864671] Backport generated by backports.git v4.19.161-1-0-g4bb568fe
Mon Feb 15 15:34:46 2021 kern.info kernel: [    8.872867] ip_tables: (C) 2000-2006 Netfilter Core Team
Mon Feb 15 15:34:46 2021 kern.info kernel: [    8.881802] nf_conntrack version 0.5.0 (8192 buckets, 32768 max)
Mon Feb 15 15:34:46 2021 kern.info kernel: [    8.907290] xt_time: kernel timezone is -0000
Mon Feb 15 15:34:46 2021 kern.info kernel: [    8.932505] PPP generic driver version 2.4.2
Mon Feb 15 15:34:46 2021 kern.info kernel: [    8.937838] NET: Registered protocol family 24
Mon Feb 15 15:34:46 2021 kern.info kernel: [    8.946607] Broadcom 43xx driver loaded [ Features: NL ]
Mon Feb 15 15:34:46 2021 kern.info kernel: [    8.956634] usbcore: registered new interface driver brcmfmac
Mon Feb 15 15:34:46 2021 kern.warn kernel: [    8.962563] pci_generic_config_write32: 48 callbacks suppressed
Mon Feb 15 15:34:46 2021 kern.warn kernel: [    8.962574] pci_bus 0000:01: 1-byte config write to 0000:01:00.0 offset 0x3c may corrupt adjacent RW1C bits
Mon Feb 15 15:34:46 2021 kern.info kernel: [    8.978310] pci 0000:00:00.0: enabling device (0140 -> 0142)
Mon Feb 15 15:34:46 2021 kern.warn kernel: [    8.983997] pci_bus 0000:00: 2-byte config write to 0000:00:00.0 offset 0x4 may corrupt adjacent RW1C bits
Mon Feb 15 15:34:46 2021 kern.warn kernel: [    8.993689] pci_bus 0000:00: 2-byte config write to 0000:00:00.0 offset 0x4 may corrupt adjacent RW1C bits
Mon Feb 15 15:34:46 2021 kern.info kernel: [    9.003373] brcmfmac 0000:01:00.0: enabling device (0140 -> 0142)
Mon Feb 15 15:34:46 2021 kern.warn kernel: [    9.009485] pci_bus 0000:01: 2-byte config write to 0000:01:00.0 offset 0x4 may corrupt adjacent RW1C bits
Mon Feb 15 15:34:46 2021 kern.warn kernel: [    9.019173] pci_bus 0000:01: 2-byte config write to 0000:01:00.0 offset 0x4 may corrupt adjacent RW1C bits
Mon Feb 15 15:34:46 2021 kern.info kernel: [    9.192073] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac4366c-pcie for chip BCM43664/4
Mon Feb 15 15:34:46 2021 kern.warn kernel: [    9.415864] brcmfmac 0000:01:00.0: Direct firmware load for brcm/brcmfmac4366c-pcie.asus,rt-ac88u.txt failed with error -2
Mon Feb 15 15:34:46 2021 kern.warn kernel: [    9.427032] brcmfmac 0000:01:00.0: Direct firmware load for brcm/brcmfmac4366c-pcie.txt failed with error -2
Mon Feb 15 15:34:46 2021 kern.info kernel: [    9.764694] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac4366c-pcie for chip BCM43664/4
Mon Feb 15 15:34:46 2021 kern.warn kernel: [    9.773517] brcmfmac 0000:01:00.0: Direct firmware load for brcm/brcmfmac4366c-pcie.clm_blob failed with error -2
Mon Feb 15 15:34:46 2021 kern.info kernel: [    9.783831] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available
Mon Feb 15 15:34:46 2021 kern.info kernel: [    9.795088] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM43664/4 wl0: Nov  5 2018 03:19:56 version 10.28.2 (r769115) FWID 01-d2cbb8fd
Mon Feb 15 15:34:46 2021 kern.warn kernel: [    9.834648] pci_bus 0001:01: 1-byte config write to 0001:01:00.0 offset 0x3c may corrupt adjacent RW1C bits
Mon Feb 15 15:34:46 2021 kern.info kernel: [    9.844456] pci 0001:00:00.0: enabling device (0140 -> 0142)
Mon Feb 15 15:34:46 2021 kern.warn kernel: [    9.850140] pci_bus 0001:00: 2-byte config write to 0001:00:00.0 offset 0x4 may corrupt adjacent RW1C bits
Mon Feb 15 15:34:46 2021 kern.warn kernel: [    9.859865] pci_bus 0001:00: 2-byte config write to 0001:00:00.0 offset 0x4 may corrupt adjacent RW1C bits
Mon Feb 15 15:34:46 2021 kern.info kernel: [    9.869584] brcmfmac 0001:01:00.0: enabling device (0140 -> 0142)
Mon Feb 15 15:34:46 2021 kern.warn kernel: [    9.875762] pci_bus 0001:01: 2-byte config write to 0001:01:00.0 offset 0x4 may corrupt adjacent RW1C bits
Mon Feb 15 15:34:46 2021 kern.warn kernel: [    9.885516] pci_bus 0001:01: 2-byte config write to 0001:01:00.0 offset 0x4 may corrupt adjacent RW1C bits
Mon Feb 15 15:34:46 2021 kern.info kernel: [   10.062100] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac4366c-pcie for chip BCM43664/4
Mon Feb 15 15:34:46 2021 kern.warn kernel: [   10.073840] brcmfmac 0001:01:00.0: Direct firmware load for brcm/brcmfmac4366c-pcie.asus,rt-ac88u.txt failed with error -2
Mon Feb 15 15:34:46 2021 kern.warn kernel: [   10.084985] brcmfmac 0001:01:00.0: Direct firmware load for brcm/brcmfmac4366c-pcie.txt failed with error -2
Mon Feb 15 15:34:46 2021 kern.info kernel: [   10.424665] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac4366c-pcie for chip BCM43664/4
Mon Feb 15 15:34:46 2021 kern.warn kernel: [   10.433456] brcmfmac 0001:01:00.0: Direct firmware load for brcm/brcmfmac4366c-pcie.clm_blob failed with error -2
Mon Feb 15 15:34:46 2021 kern.info kernel: [   10.443761] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available
Mon Feb 15 15:34:46 2021 kern.info kernel: [   10.455006] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM43664/4 wl0: Nov  5 2018 03:19:56 version 10.28.2 (r769115) FWID 01-d2cbb8fd
Mon Feb 15 15:34:46 2021 user.info kernel: [   10.480820] kmodloader: done loading kernel modules from /etc/modules.d/*

So either way, the firmware load is failing.

One thing concerning the snapshot. In the old version the leds of the wireless radios were active. In the recent version they are just off.

Wi-Fi LED is a bit glitchy on OpenWrt for some reason. I mapped the GPIO numbers correctly, so not much I can do there.

Your logs on snapshot and 19.07.7 don't actually put out anything that would break wireless. Ignore the CLM blob error on your side, it's just a regulation thing, it wouldn't break anything as far as I know.

Take a look at mine. radio0 would just never work on my hardware.

[    9.222075] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac4366c-pcie for chip BCM43664/4
[   11.822031] ieee80211 phy0: brcmf_msgbuf_query_dcmd: Timeout on response for query command
[   11.830328] ieee80211 phy0: brcmf_c_preinit_dcmds: Retrieving cur_etheraddr failed, -5
[   11.838276] ieee80211 phy0: brcmf_bus_started: failed: -5
[   11.843700] ieee80211 phy0: brcmf_attach: dongle is not responding: err=-5

Still no connection on 19.07.7? If so, can you head back to snapshot and do a speedtest over Wi-Fi? I'm wondering if you can get performance like 300mbps on 5 & 2.4GHz.

Below you will find speedtests from two different clients. The distance of the clients to the ASUS was about 1m.

I did the speedtests with iperf3. As Server my Gbit wired PC was used. Client 1 is an old MacBook Pro (8,1), only capable of Wifi 802.11n. Client 2 is a cell phone (Samsung Galaxy S10E).

Client 1 results, connected to 5GHz radio

Accepted connection from 192.168.5.23, port 50802
[ 5] local 192.168.5.2 port 5201 connected to 192.168.5.23 port 50803
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 35.5 MBytes 297 Mbits/sec
[ 5] 1.00-2.00 sec 36.5 MBytes 307 Mbits/sec
[ 5] 2.00-3.00 sec 37.3 MBytes 313 Mbits/sec
[ 5] 3.00-4.00 sec 35.6 MBytes 298 Mbits/sec
[ 5] 4.00-5.00 sec 35.1 MBytes 294 Mbits/sec
[ 5] 5.00-6.00 sec 34.9 MBytes 293 Mbits/sec
[ 5] 6.00-7.00 sec 35.5 MBytes 298 Mbits/sec
[ 5] 7.00-8.00 sec 35.6 MBytes 298 Mbits/sec
[ 5] 8.00-9.00 sec 35.6 MBytes 298 Mbits/sec
[ 5] 9.00-10.00 sec 35.3 MBytes 296 Mbits/sec
[ 5] 10.00-10.02 sec 779 KBytes 325 Mbits/sec


[ ID] Interval Transfer Bitrate
[ 5] 0.00-10.02 sec 358 MBytes 299 Mbits/sec receiver

Client 1 results, connected to 2.4GHz radio

Accepted connection from 192.168.5.23, port 51472
[ 5] local 192.168.5.2 port 5201 connected to 192.168.5.23 port 51473
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 19.3 MBytes 162 Mbits/sec
[ 5] 1.00-2.00 sec 19.8 MBytes 166 Mbits/sec
[ 5] 2.00-3.00 sec 19.3 MBytes 162 Mbits/sec
[ 5] 3.00-4.00 sec 19.6 MBytes 164 Mbits/sec
[ 5] 4.00-5.00 sec 19.8 MBytes 166 Mbits/sec
[ 5] 5.00-6.00 sec 19.6 MBytes 164 Mbits/sec
[ 5] 6.00-7.00 sec 20.0 MBytes 168 Mbits/sec
[ 5] 7.00-8.00 sec 19.6 MBytes 165 Mbits/sec
[ 5] 8.00-9.00 sec 19.7 MBytes 165 Mbits/sec
[ 5] 9.00-10.00 sec 19.7 MBytes 166 Mbits/sec
[ 5] 10.00-10.07 sec 1.49 MBytes 172 Mbits/sec


[ ID] Interval Transfer Bitrate
[ 5] 0.00-10.07 sec 198 MBytes 165 Mbits/sec receiver

Client 2 results, connected to 5GHz radio

Connecting to host 192.168.5.2, port 5201
[ 4] local 192.168.5.244 port 41048 connected to 192.168.5.2 port 5201
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 57.2 MBytes 479 Mbits/sec
[ 4] 1.00-2.01 sec 58.8 MBytes 489 Mbits/sec
[ 4] 2.01-3.01 sec 60.3 MBytes 507 Mbits/sec
[ 4] 3.01-4.01 sec 63.0 MBytes 528 Mbits/sec
[ 4] 4.01-5.01 sec 61.2 MBytes 512 Mbits/sec
[ 4] 5.01-6.00 sec 57.1 MBytes 484 Mbits/sec
[ 4] 6.00-7.00 sec 60.1 MBytes 504 Mbits/sec
[ 4] 7.00-8.00 sec 59.3 MBytes 498 Mbits/sec
[ 4] 8.00-9.01 sec 61.7 MBytes 515 Mbits/sec
[ 4] 9.01-10.00 sec 59.2 MBytes 497 Mbits/sec


[ ID] Interval Transfer Bandwidth
[ 4] 0.00-10.00 sec 598 MBytes 501 Mbits/sec sender
[ 4] 0.00-10.00 sec 598 MBytes 501 Mbits/sec receiver

Client 2 results, connected to 2.4GHz radio

Connecting to host 192.168.5.2, port 5201
[ 4] local 192.168.5.243 port 46008 connected to 192.168.5.2 port 5201
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 11.2 MBytes 93.8 Mbits/sec
[ 4] 1.00-2.00 sec 10.2 MBytes 86.0 Mbits/sec
[ 4] 2.00-3.02 sec 10.8 MBytes 88.9 Mbits/sec
[ 4] 3.02-4.02 sec 9.90 MBytes 82.6 Mbits/sec
[ 4] 4.02-5.00 sec 9.67 MBytes 82.9 Mbits/sec
[ 4] 5.00-6.00 sec 10.5 MBytes 88.0 Mbits/sec
[ 4] 6.00-7.00 sec 9.59 MBytes 80.4 Mbits/sec
[ 4] 7.00-8.00 sec 10.4 MBytes 87.6 Mbits/sec
[ 4] 8.00-9.00 sec 10.4 MBytes 86.9 Mbits/sec
[ 4] 9.00-10.00 sec 10.3 MBytes 86.0 Mbits/sec


[ ID] Interval Transfer Bandwidth
[ 4] 0.00-10.00 sec 103 MBytes 86.3 Mbits/sec sender
[ 4] 0.00-10.00 sec 103 MBytes 86.3 Mbits/sec receiver

2 Likes

This is amazing! Both channels work fine and you get decent speeds! That's really good.
There might be something wrong with my hardware which breaks Wi-Fi. I'm going to play around with it on the DTS file and see if I can make it work on mine too.

By the way, I realised that I didn't include LED configuration on the builds which is where you were having problems. I'll get that fixed.

It was really helpful to have someone else test it on the same hardware. I can finally confirm that Wi-Fi works fine. Looks like this device might actually have a chance of appearing in the official trunk.

I'll write down about the CFE difference. This information will be included in the device page on OpenWrt website.

try different channels i had such issues.

Can't do that, at least on the 2.4GHz band. That one won't even start :smiley:

when i changed channel to ones that didn't work to bring it up again only full reboot helped. Edit the config and reboot. I took the settings for channels/power from merlin

The physical layer, the phy0, won't start on boot up. The firmware does not even detect the radio, so I can't make any configurations.

I flashed DD-WRT to see how Wi-Fi would work. After flashing OpenWrt back, Wi-Fi just magically started working. Getting decent speeds on both bands like you have, super odd.
Edit: I'm assuming that DD-WRT changed something in the NVRAM which fixed whatever issue it was causing on OpenWrt.

Anyway, I'm working on the Realtek switch driver for RTL8365MB. It uses rtl8367s driver with a proprietary file which adds RTL8365MB support. I'm trying to make it compile on OpenWrt SDK. I'm not sure whether we can get the proprietary source code to be allowed in OpenWrt trunk. I'm determined to make it work anyway.

After that, I'll do few touches on the DTS file and this device is ready to rock!

1 Like

Well, that's what I call strange behavior. Did you reset the NVRAM to the default settings before or after flashing your OpenWRT build (e.g. using the command on the CFE web interface?)? But in the end it is the result that counts.
One thing that I came across while playing around with the WiFi interfaces is the "Maximum transmit power" setting. The drop-down menu offers the maximum setting for the transmission power (according to the national borders of Germany) 20 dBm or 100 mA. After the drop-down box, however, a value of 31 dBm is given as the current power level. Maybe it's just a cosmetic aspect. I'll play around with the other values ​​in the drop-down box to see if any of the selectable values ​​can make a difference.

Regarding the Realtek switch, I am impressed with your efforts to make the build perfect for the router. This would make the build even better than DD-WRT's builds. When using your device with DD-WRT, have you noticed that the ports are mixed up in the web GUI, e.g. the physical port 1 corresponds to port 3 in the GUI?

I doubt that the acceptance of non-free firmware in the OpenWRT project is very high as they highlight the concept of FLOSS (Free and Open Source Software). But maybe your build can be like some PLC device builds. I have some Devolo devices in my head that have closed source PLC firmware that can only be picked up by anyone. The device pages of the OpenWRT wiki mention this fact.

Either way, I'm more than excited about the planned next release and will be happy to test it.

I never reset the NVRAM, like, ever. All those test builds that were run on the device (way back from 2020) must've messed it up.

Let me know of your findings about Wi-Fi. It'll be very useful to put them on the device page.

I have only gathered information from the command-line. I didn't have the chance to try that, sorry.

For the next release, I plan to have Realtek switch working, along with a small fix to Broadcom switch made on the DTS file. Call it the final release.

I've been working on the RTL8365MB switch driver and it probably needs to be rewritten which is way above my C knowledge, unfortunately.

To put it bluntly, there's the rtl8367c_drv.c file that doesn't exist on the rtl8367s/c driver.

#define NAME			"rtl8365mb"

MODULE_DESCRIPTION("Realtek " NAME " support");
MODULE_AUTHOR("ASUS");
MODULE_LICENSE("Proprietary");

This file could be modified to work with the existing rtl8367s/c driver.
Or, since it requires a lot of functions that are undeclared on the existing rtl8367s/c driver, the whole RTL8365MB source code from Asus tarball could be modified to compile on OpenWrt.
Both of which I'm not capable of managing. :frowning:

Been busy the past few days. So far I have the impression that regardless of the value I select from the "Maximum transmit power" drop-down box, the effective transmit power does not change. But unfortunately I don't have any measurement technology to support this assumption by measuring the effected radiated power at the antenna.

In the web interface, under "Current power", 31 dBm is always displayed, regardless of the country selected and the selected transmission power. And the displayed transmission values of the wireless devices do not change either.

1 Like

Ok, maybe I should give myself a wee bit more credit of my capabilites. I did manage to compile the driver as a kernel module and load it on the device. It fails, gasp, however I actually get something useful on dmesg. I'll continue messing with the driver with very superficial C knowledge that I have ;P.

[   68.110138] rtl8365mbrtl8365mb initialized(-1)(retry:10) failed
[   68.230088] rtk port_phyEnableAll Failed!(15)
[   68.350094] rtk port_macForceLink_set ext_Port0 Failed!(15)
[   68.470086] get ok, chk 0x1311:0(0x1016), 0x1305:0(b4~b7:0x1)
[   68.475836] reset 0x1311 (0x1016)
[   68.479152] reset 0x1305 (10)
[   68.600085] (2) get again ok, chk again 0x1311:0(0x1016), 0x1305:0(b4~b7:0x1)

A few printk commands for debugging helped solving where it was failing :smiley:

[37599.230100] initialize the switch
[37599.230103] running rtk_switch_init
[37599.233428] probing switch
[37599.236918] at force probe stage
[37599.239624] setting initial state
[37599.242878] initial state set
[37599.246196] at rtl8367c case
[37599.249163] initializing 8367c
[37599.252052] initialized a switch port
[37599.255110] initialized a switch port
[37599.258773] initialized a switch port
[37599.262444] initialized a switch port
[37599.266111] initialized a switch port
[37599.269776] initialized 8367c
[37599.273447] rtl8365mb initialized(0)(retry:0)
[37599.400084] rtk port_phyEnableAll ok
[37599.520080] rtk port_macForceLink_set ext_Port0 ok
[37599.640080] get ok, chk 0x1311:0(0x1016), 0x1305:0(b4~b7:0x1)
[37599.645831] reset 0x1311 (0x1016)
[37599.649148] reset 0x1305 (10)
[37599.770077] (2) get again ok, chk again 0x1311:0(0x1016), 0x1305:0(b4~b7:0x1)

Edit: updated the log with more verbose debug logs.

Can you try and see if USB devices work on the router? Mine won't detect anything at /dev/sda

Sure, no problem. I will run some tests tomorrow.

Well I followed the guide from the OpenWrt Wiki, but I did not succeed, please see below:

root@AP_SQ:~# opkg install kmod-usb-storage
Unknown package 'kmod-usb-storage'.
Collected errors:
 * pkg_hash_fetch_best_installation_candidate: Packages for kmod-scsi-core found, but incompatible with the architectures configured
 * pkg_hash_fetch_best_installation_candidate: Packages for kmod-usb-storage found, but incompatible with the architectures configured
 * opkg_install_cmd: Cannot install package kmod-usb-storage.
root@AP_SQ:~# opkg install usbutils
Package usbutils (013-2) installed in root is up to date.
root@AP_SQ:~# lsusb -t
/:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/0p, 480M
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ohci-platform/2p, 12M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/2p, 480M
root@AP_SQ:~#

Any idea how to overcome the problem with the incompatible architecture?

Don't install any kmod packages for now. kmod-usb & kmod-usb3 comes with the image which should be enough for the USB drive to appear at /dev/ as sda or sd*. Check there and see if it appears.

I included kmod-usb-storage while compiling the image but USB would still not appear. I'll send you the image with it if the USB drive doesn't appear on yours using the current image.

Ok, please see the output on the console. I am using a 16GB USB stick, FAT32 format in the blue USB3 slot:

root@AP_SQ:~# ls /dev
bus mtd1ro mtdblock4 ubi0
console mtd2 null ubi0_0
cpu_dma_latency mtd2ro port ubi0_1
full mtd3 ppp ubi_ctrl
gpiochip0 mtd3ro ptmx ubiblock0_0
hwrng mtd4 pts urandom
kmsg mtd4ro random watchdog
log mtdblock0 shm watchdog0
mtd0 mtdblock1 tty zero
mtd0ro mtdblock2 ttyS0
mtd1 mtdblock3 ttyS1
root@AP_SQ:~#

So no sign of a sd* device.

I am trying to compile a version with kmod-usb-storage included into the kernel with additional support for the filesystems.

But you are right the device should be visible only with the basic usb support.