I understand the Broadcom wireless issues (No FOSS drivers etc). I have a router with bad WiFi but it does boot up and the Ethernet switch seems to work fine. It is a dual core CPU ( ARM Cortex-A9, 800 MHz 2 cores) decent RAM and flash with USB 3.0 device.
So, rather than throwing it away, I would prefer to upcycle it using openwrt as a standalone services device in my home network, say cheap NAS/DLNA device, privoxy, dns proxy, wireguard etc. Not all, just few examples run by other devices right now.
So, other than WiFi (dead for me anyway), is this device supported by openwrt properly? Are there any other limitations on using Broadcom chipsets?
Do you know for sure that there is a difference? I read somewhere that R designation was for a certain type of retail channel. FCC certification says that the cert. is for both. Even wikidevi redirect 56R to 56U page. The device and the specs. outside the box look exactly the same for 56U and 56R.
No, I'm not, but it's you that has to be sure, not me, unless you enjoy digital bricks ,)
Problem is, even if the hw is the same, the firmware and it's layout might be different,
resulting in a device stuck in a boot loop, or worse.
Only way to verify it, is to compare an AC56R with an AC56U over serial console (or
perhaps binwalk/compare the firmware files), where you can see everything below the UI.
@frollic I appreciate your concern. But, I just confirmed that the upgrade firmware is same for both. Here are the urls for their latest firmware for both routers.
There is a md5 checksum given for both. It is identical. In addition, I downloaded the firmware and did a binary compare on both files. Then I did my own shasum -a 256. No differences! It is interesting that the web interface on the router shows the correct model number for RT-AC56R but the firmware is identical.
Not necessarily, the OEM bootloader might select different DTS files depending on the device. A blanket all-clear isn't possible just because the downloadable OEM images are bit-identical.
I can't say if that's the case here, but it's technically possible (and would maintenance easier for the OEM).
Afaik the Asus routers that end with U were the ones with USB ports, but the AC56R has USB ports too, so now it does not seem to mean USB ports anymore.
NOTE: all the "R" versions (for example RT-N66R) are the same as their "U" counterparts, they are just different packages aimed at large retailers. The firmware is 100% compatible with both U and R versions of the routers. Same with the "W" variants that are simply white.
Since asuswrt-merlin developers work only on firmware for Asus devices they know them very well so it's probably right.
If you confirm that your device runs fine with the RT-AC56U firmware I'll update the wiki with this information.
Afaik the only thing that won't work properly in OpenWrt is the wifi radios. The CPU and ethernet and USB should all work fine
OpenWrt project has been really useful for me. For the team, I will sacrifice the hardware (If it happens) to test this theory. If it works, it will be upcycling for sure. I really don't care about WiFi. It is half dead anyway. When I did ping to a server few thousand miles away, the WiFi was eating packets even in AP mode., bad speed test too.
Do you want to test with Asus RT-AC56U firmware or OpenWrt? 19.07 or 21 RC3? If OpenWrt, what tests will confirm that it is working?
You want to install OpenWrt so test with OpenWrt directly. Either version is good, this device was added ages ago so the hardware config should be the same in both versions.
(software versions of more recent release are of course newer and that should be better if you want to install optional packages like samba for file sharing and wireguard and whatnot)
I just tried uploading openwrt-21.02.0-rc4-bcm53xx-generic-asus_rt-ac56u-squashfs.trx and also 19.07 stable using the web interface. There is some software check in the existing firmware that prevents it from uploading. I do not get any error message, it just comes back to the update screen. I tried the Asus ac-56u firmware. As we already established that it is the same, it does upload. Is there any way to bypass the firmware check?
If that image does not work, follow the "Install via TFTP" instructions on that page. TFTP is a recovery system integrated in bootloader and usually does not check if the firmware you send is "correct" (or from Asus), so it should work.
Here is the kernel log. I see some errors but I see that it booted in to openwrt-21.02.0-rc4. Few glaring issues for me were random mac address on the switch and
pci_bus 0000:00: 2-byte config write to 0000:00:00.0 offset 0x4 may corrupt adjacent RW1C bits
I think those PCI errors are harmless.
Seems like the generic PCI driver that tries to detect stuff but then fails.
But the PCI subsystem is then taken over and initialized correctly by what seems a device-specific PCI driver called "bcma-pci-bridge", and all devices on the bus are detected.
[ 4.173677] bcma-pci-bridge 0000:01:00.0: enabling device (0140 -> 0142)
[ 4.180394] bcma-pci-bridge 0000:01:00.0: bus1: Found chip with id 43217, rev 0x00 and package 0x08
[ 4.189442] bcma-pci-bridge 0000:01:00.0: bus1: Core 0 found: ChipCommon (manuf 0x4BF, id 0x800, rev 0x27, class 0x0)
[ 4.200029] bcma-pci-bridge 0000:01:00.0: bus1: Core 1 found: IEEE 802.11 (manuf 0x4BF, id 0x812, rev 0x1E, class 0x0)
[ 4.210721] bcma-pci-bridge 0000:01:00.0: bus1: Core 2 found: PCIe (manuf 0x4BF, id 0x820, rev 0x14, class 0x0)
[ 4.220851] bcma-pci-bridge 0000:01:00.0: bus1: Found rev 12 PMU (capabilities 0x108C260C)
[ 4.305402] bcma-pci-bridge 0000:01:00.0: bus1: Using SPROM revision 8 provided by platform.
[ 4.305421] bcma-pci-bridge 0000:01:00.0: bus1: PMU resource config unknown or not needed for device 0xA8D1
[ 4.313690] bcma-pci-bridge 0000:01:00.0: bus1: Workarounds unknown or not needed for device 0xA8D1
[ 4.353976] bcma-pci-bridge 0000:01:00.0: bus1: Bus registered
[ 4.360080] pci 0001:00:00.0: enabling device (0140 -> 0142)
[ 4.365756] bcma-pci-bridge 0001:01:00.0: enabling device (0140 -> 0142)
[ 4.372471] bcma-pci-bridge 0001:01:00.0: bus2: Found chip with id 0x4352, rev 0x03 and package 0x01
[ 4.381603] bcma-pci-bridge 0001:01:00.0: bus2: Core 0 found: ChipCommon (manuf 0x4BF, id 0x800, rev 0x2B, class 0x0)
[ 4.392185] bcma-pci-bridge 0001:01:00.0: bus2: Core 1 found: IEEE 802.11 (manuf 0x4BF, id 0x812, rev 0x2A, class 0x0)
[ 4.402864] bcma-pci-bridge 0001:01:00.0: bus2: Core 2 found: ARM CR4 (manuf 0x4BF, id 0x83E, rev 0x02, class 0x0)
[ 4.413196] bcma-pci-bridge 0001:01:00.0: bus2: Core 3 found: PCIe Gen2 (manuf 0x4BF, id 0x83C, rev 0x01, class 0x0)
[ 4.423693] bcma-pci-bridge 0001:01:00.0: bus2: Core 4 found: USB 2.0 Device (manuf 0x4BF, id 0x81A, rev 0x11, class 0x0)
[ 4.434663] bcma-pci-bridge 0001:01:00.0: bus2: Found rev 17 PMU (capabilities 0x10A22B11)
[ 4.434749] bcma-pci-bridge 0001:01:00.0: bus2: SPROM offset 0x800
[ 4.466192] bcma-pci-bridge 0001:01:00.0: bus2: Invalid SPROM read from the PCIe card, trying to use fallback SPROM
[ 4.493149] bcma-pci-bridge 0001:01:00.0: bus2: Using SPROM revision 11 provided by platform.
[ 4.493165] bcma-pci-bridge 0001:01:00.0: bus2: PMU resource config unknown or not needed for device 0x4352
[ 4.503683] bcma-pci-bridge 0001:01:00.0: bus2: Workarounds unknown or not needed for device 0x4352
[ 4.503699] bcma-pci-bridge 0001:01:00.0: bus2: Switched to core: 0x83C
[ 4.504138] bcma-pci-bridge 0001:01:00.0: bus2: Bus registered
And reading down after that I see USB 2.0 and USB 3.0 controllers that are started and working
(this is the USB 3.0, the USB 2.0 has an obvious name)
[ 6.680197] xhci-hcd 18023000.usb: xHCI Host Controller
[ 6.685469] xhci-hcd 18023000.usb: new USB bus registered, assigned bus number 3
[ 6.693203] xhci-hcd 18023000.usb: hcc params 0x02501164 hci version 0x100 quirks 0x0000001000010010
[ 6.702406] xhci-hcd 18023000.usb: irq 38, io mem 0x18023000
So I would say all you needed is up and running, it's just spamming the logs.
As for the random MAC errors, what you see in the kernel log is irrelevant, in OpenWrt the code that is actually detecting and setting the mac should run later when the system mounts the root filesystem and starts up the operating system (doing kernel patches for things you can do with a simple script later is a waste of resources)
so it's things that happen after this and aren't kernel events so you don't see them in boot log
[ 14.251382] mount_root: overlay filesystem has not been fully initialized yet
[ 14.258792] mount_root: switching to ubifs overlay
reading the MAC from nvram and setting it is handled by the init script here that runs every boot. (these don't have a special name set here so they use the generic command)
Can you please check if your device has the correct MAC after it has finished booting?
Check from Luci Network -> Interface page or if you are connected on serial or ssh you can use
ip a
This is an example output where you see lo interface which is loopback and is a virtual interface, and then eth0 and eth1 interfaces, and a couple bridges that actually have the IP and represent the LAN and WAN interfaces you see in Luci web interface.
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether e4:95:6e:43:30:3a brd ff:ff:ff:ff:ff:ff
inet6 fe80::e695:6eff:fe43:303a/64 scope link
valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br-wan state UP group default qlen 1000
link/ether e4:95:6e:43:30:3b brd ff:ff:ff:ff:ff:ff
12: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether e4:95:6e:43:30:3a brd ff:ff:ff:ff:ff:ff
inet 192.168.11.254/24 brd 192.168.11.255 scope global br-lan
valid_lft forever preferred_lft forever
inet6 fe80::e695:6eff:fe43:303a/64 scope link
valid_lft forever preferred_lft forever
28: br-wan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether e4:95:6e:43:30:3b brd ff:ff:ff:ff:ff:ff
inet 192.168.100.131/24 brd 192.168.100.255 scope global br-wan
valid_lft forever preferred_lft forever
inet6 fe80::e695:6eff:fe43:303b/64 scope link
valid_lft forever preferred_lft forever
These devices aren't new and the lack of wifi drivers does not make them very attractive.
Nobody is going to "improve" the situation massively, most you can expect is kernel updates (to run the latest and greatest release) and bug fixing.
But so far it seems to be mostly OK.
Given the age and the chipset manufacturer, this is all I expect. This will suffice.
What mac addresses do I expect? I see one Asus MAC address 2c:56:dc for all of the following eth0, br-lan, wlan0, eth0.1@eth0 & eth0.1@eth1.
Following use random mac addresses.
3: eth1: |link/ether 86:ad:24:66:29:9e brd ff:ff:ff:ff:ff:ff|
4: eth2: |link/ether fa:fc:d9:64:ec:7a brd ff:ff:ff:ff:ff:ff|
I am posting on a laptop connected via ethernet cable to this ASUS RT-AC56R router. WAN for this router is connected to my main19.08 Archer C7 by another ethernet cable. So the basic networking and routing seems to work. I have not tested speed or anything else yet.
BTW I do see a bug. Status -> Overview Page -> LAN DHCP lease shows expired for both IPV4 and IPV6. Although I just connected to it. WAN lease time is correct.
Should be printed in a sticker attached to the device, usually the same sticker has also model name and whatnot. You can also write it down and restart the router, and see if it keeps the same address.
But since you mention that it is an Asus MAC it's probably the correct MAC assigned to this device at the factory, OpenWrt does not go out of its way to figure out that this is an Asus device so it should generate a random Asus MAC. It either reads the MAC from the factory data flash partition or it generates a completely random MAC every boot.
The hardware design of these devices is a bit weird, they might be not wired to anything, unused. There is this comment in the code of the script reading network settings and MAC, above
# On BCM4708 / BCM4709(4) there are 3 Ethernet interfaces connected to 3 switch
# ports. It's up to vendor which to use.
the interfaces you list above are eth0 (an actual ethernet controller in the main CPU, wired internally to the onboard smart switch as said in the comment), br-lan (virtual interface, a LAN bridge that joins the ethernet LAN to the wireless network), wlan0 (the wireless network), eth0.1@eth0 & eth0.1@eth1 (these are two VLANs that split the ports of the onboard smart switch in two separate groups, the four LAN ports and a WAN port. It seems all the pysical ethernet ports in this device are in fact a smart switch, is a common thing).
So that would already account for all the interfaces you can actually use.
You can check on your Archer C7 in the DHCP lease list if the MAC address it sees is the same as the one you see from the Asus device.
I have not tested speed or anything else yet.
I'm not in a hurry, when you try out USB ports and you confirm they work fine I'm calling it "OK" and I will proceed to update the wiki with this information (that the devices are indeed the same and everything works)
maybe it gave the DHCP lease before adjusting the clock from the network so it jumped 50 years or so from "unix year zero" in 1970 to now, I don't know. This part of OpenWrt is generic to all devices though, (Luci web interface, DHCP server) so all devices should act the same. Just give it some time to settle and it should probably refresh that entry.
TLDR: Confirmed that it works as a wired device. (My WiFi is dead so I cannot test it). Also confirmed that both USB ports work. We can say that RT-AC56U openwrt firmware works on RT-AC56R.
MAC address is indeed the one on the box. I was under the impression that each port on the device would have a different MAC address.
Today I connected the device directly to my cable modem. It works, decent net speed. Also did a packet loss test from this site. No errors.
I also checked both USB ports (2.0 and 3.0) with a Debian install USB stick. I followed USB howto.
root@RT56R:/dev# 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
|__ Port 2: Dev 3, If 0, Class=, Driver=usb-storage, 480M
/dev/sda: UUID="2021-01-11-15-55-51-00" LABEL="Debian RPD M-A 1" TYPE="iso9660"
/dev/sda1: UUID="2021-01-11-15-55-51-00" LABEL="Debian RPD M-A 1" TYPE="iso9660"
/dev/sda2: UUID="4B31-C439" VERSION="FAT12" TYPE="vfat"
root@RT56R:/dev# mount /dev/sda1 /tmp/usb1
root@RT56R:/tmp/usb1# ls
EFI debian isolinux
README.html dists live
README.mirrors.html doc md5sum.txt
README.mirrors.txt g2ldr pics
README.txt g2ldr.mbr pool
autorun.inf install setup.exe
boot install.386 tools
css install.amd win32-loader.ini
root@RT56R:/tmp/usb1# cat autorun.inf
[autorun]
open=setup.exe
icon=setup.exe,0
label=Install Debian GNU/Linux
[Content]
MusicFiles=false
PictureFiles=false
VideoFiles=false
GREAT Work OpenWrt team. Looking forward to a stable release so that I can start using this device in the home.
From hardware specs, this device has a stronger CPU than your Archer C7
dual Armv7 cores at 800 Mhz vs single core MIPS 750 Mhz
so you can also use it as main router, reconfigure the Archer as a pure access point connected to an ethernet network https://openwrt.org/docs/guide-user/network/wifi/dumbap and move it to a better place for wifi coverage in your home.
I was thinking the same thing. BTW I recently bought a used Netgear R6260. I hopes that it will be fully supported by 21.02 when released. Isn't that better hardware compared to RT-AC56R and C7? I will use R6260 as the main router, convert Asus as dumb AP (to get rid of the router functions, not for wireless) and use it for other services. I am still thinking of using RT-AC56R as a NAS (it has USB 3 vs. usb 2 on Netgear R6260), DNS server and Wireguard Server. Archer C7 will upgrade TL-WDR3600 in another place
If I convert a router in to dumb AP does it still work with VLANs? I do have three wireless VLANs in the home running on C7 right now.
BTW Please update the wiki... For TFTP upload, I had to factory reset RT-AC56R. (My IP subnet was not 192.168.1.x).
And I'll link these to the device pages as well. The whole page is an autogenerated template anyway, so even just that is better than its current state.
Also, if you want better instructions about installing OpenWrt in that device, other than the snippets someone wrote in commit messages and my own interpretation, please open a new thread and maybe others that know more about them can help
