Is this change only for the ath79 platform or global? I'll update the DTS file according to this if it's the latter.
Edit: Now I get to play around with that, I see it's just a naming standart set by OpenWRT. I'll update the DTS file accordingly.
I figured Broadcom switch works at port 7, eth1. Realtek switch won't work without proper drivers.
The router is working properly with the latest commit on my fork.
This router has two cores but I couldn't make eth0 work under port 5, 6, and 8.
Screenshots from LuCI:
That is pretty much what prevents it from being a useful home gateway device. Right now, I make use of this router as a managed switch, if you can believe it.
A shame, it would have been too nice. Because of its decent WLAN coverage I use the router as AP and as firmware Merlin-WRT to be able to put the guest WLAN into a separate VLAN.
Nevertheless thank you for bringing OpenWRT to the RT-AC88u.
Thank you. Actually, you wouldn't need to have an open-source wireless driver to make it work on OpenWrt. I did load Broadcom wireless firmware on OpenWrt (it's a very standart procedure, nothing specific that you need to do) but Wi-Fi just wouldn't work.
I believe there needs to be changes made on the DTS file for the device but I stopped working on it before I got there. This is where I left off:
There is support for Phicomm K3 AC3150 which is very similar router, i use it as a daily driver and is very stable. I use binary wifi drivers extracted from the Asus FWs and the speeds are great. Look around in the forum. Also check https://github.com/coolsnowwolf/lede openwrt fork, it is a chinese thing but very popular and doesn't care if something is proprietary or not.
Thatβs actually what @npcomplete and I did. We tested a bunch of wireless firmware on different versions, extracted from the kernel modules from Asus and Linksys firmwares.
I think the wireless firmware fails to run on newer kernels which I believe a specific configuration on the DTS file would solve it. Some examples are there on the Notion page where I stopped working on it.
@arinc9
I tried your openwrt fork today because I was really curious to see if I could get it working on my hardware. After manually adding libcap from the openwrt repository to the / package / libs directory, the compilation worked fine. I had to use the -i (ignore) switch to suppress an error on some TP-Link Archer device. Then I flashed the trx file via the router's CFE interface and was able to access the LUCI web interface. At least everything is working fine at first glance, even a wireless connection is possible, which I did not expect.
So here comes my question. Do you think you could update your fork to the latest snapshot or, alternatively, commit your changes to the openwrt master?
That's kind of broken. You won't be able to connect and maintain stable connection, because the wireless firmware fails to start on Linux kernel 5 and newer. I plan to put my changes on the latest version of OpenWrt 19.07 to see if the firmware works on kernel 4.14.x
In the meantime, I will update the current fork to the latest master commit as you requested. There's a change on upstream that conflicts with one of my patches. I'm working on solving it.
Did putting the OpenWrt trx image on the CFE web UI work?
I had to run a TFTP server and a command like http://192.168.1.1/do.htm?cmd=flash+-noheader+192.168.1.2:firmware.trx+flash0.trx on the browser to bypass the image integrity check.
Edit: That conflict is a bigger problem than I thought. I'll work on it in the upcoming days.
@arinc9
Thank you for your quick reply and your efforts of updating the repro.
Well wireless connections are kind of fractile. For example 802.11w Management Frame Protection has to be disabled, otherwise for me no WLAN encrypted connection is possible with devices like Galaxy S10e or Macbook Pro.
Concerning the flash from CFE I had no real problems. First I reset the NVRAM values to default than I flashed the trx file without problems. Maybe this comes from the fact that I use Merlin 386.1.2 and not on of the official 386.4 versions of ASUS. Maybe the reason are different versions of CFE.
Take your time. No need to rush because in my opinion the your firmware is already doing a marvelous job. It is just the wish to be well prepared for future security updates, that drives my asking.