Xiaomi Mi Router 4A Gigabit Edition (R4AG/R4A Gigabit) -- fully supported and flashable with OpenWRTInvasion

watched your videos on youtube Installing OpenWrt on the Xiaomi 4A will it work on version 2.18.28 ? i cant download the latest version

1 Like

Hi is that firmware would work on my Mi 4A Non Giga ?

Yes, it will work.

1 Like

It's not that difficult to make it work on windows, If there is a right package "pycryptodome" instead of pycrypto which is deprecated. I would suggest to change requirements.txt from acecilia github, since it's confirmed working on linux by Brett. I can make quick tutorial if someone wants to run under windows, if there is an interest give a like to my post. BTW - hoddy if it was not clear I was having issues with deprecated package pycrypto. Never with acecilia instructions on how to use this exploit.

3 Likes

@araujorm What would I need to do to compile your 19.07.04 but using more recent commits to mt76? The reason is I'm currently testing WDS bridge between 2 identical R4A Gig devices but observing half the throughput for iperf3 TX testing (directly between the devices) and there are some more recent commits in the mt76 issue list that may resolve this. I can get expected speed when TX is from an Android phone.

To compile my build you need to clone my repo and checkout the 19.07 branch or the 19.07.04 tag, then it's the usual stuff (make menuconfig and so on).

My 19.07 branch has a commit on top of it that replaces the URL and commit hash for the mt76 package with the latest commit from here:

This latest is a fork of the mt76 19.07 branch with some backported patches from master, or at least my attempt to do so. I've stopped trying to backport more because the differences are so many that at a point it became mostly impossible :frowning:

You can try to replace the URL and commit to correspond to the latest on the official mt76 master, but it will fail since a lot of it now depends on kernel 5. I've tried but gave up...

Hopefully openwrt 20 stable release won't be much further to come out, too. When it does, we won't need this anymore. But until then...

But should you make any progress please share :slightly_smiling_face:

Thanks, it's been a long time since I've compiled on linux so not familiar ground and looking to bounce an idea - does the following approach sound viable...

This commit shows how the kernel version is defined for each target

These commits drop kernel 4.14 support for kernel and ramips:


Within the mt76 repo I cannot see anything that is aligned to kernel version (only specific operwrt releases).

Therefore, would potentially a build work by using mt76 master and openwrt master but with the above commit reverted, along with adjusting the logic for the target kernel to be 4.14 as the first commit link above has changed? The second commit link above removes all the patches for 4.14, and therefore it may work if they are still present.

R4AC(100m) global firmware version 3.0.5:

http://cdn.cnbj1.fds.api.mi-img.com/xiaoqiang/rom/r4ac/miwifi_r4ac_firmware_2c4a7_3.0.5_INT.bin

R4A Giga global firmware version 3.0.24:
http://cdn.awsde0-fusion.fds.api.mi-img.com/xiaoqiang/rom/r4a/miwifi_r4a_all_03233_3.0.24_INT.bin

1 Like

The problem is that mt76 driver master code uses functions and symbols that are only present in newer kernels. Therefore it's impossible to compile it with kernel 4.14 which is what is present in openwrt 19.07.

Anyway the only advantage right now in using openwrt 19.07.04 is stability, and the possibility to install packages from the repo (which, as I said some posts earlier, doesn't fully work with my build because the kernel vermagic isn't the same and I can't replicate it). But as I said it won't matter for much longer since I'm convinced OpenWRT 20 should be around the corner, most likely before the end of the year (wishful thinking on my part, perhaps, but some people here have already said they've been using the snapshot builds with success).

Note that there's nothing wrong with kernel 5.x, it's been around for some time and is quite stable, but a few things have changed. I just didn't change myself to use OpenWRT master version on my device because VLAN tagging wasn't working from Luci last time I checked - on kernel 5 native switch support was officially added and the old method used by OpenWRT (which wasn't "official") has now been abandoned. Last time I checked however it required one to use scripts on startup to configure VLAN tagging, being quite cumbersome to make it work (please don't confuse hardware VLAN tagging with software VLAN tagging, as MT7621 devices like this router have an hardware switch and I'm talking only about that). But I haven't been checking lately if they already implemented that or not in the uci subsystem (which must be done before they implement that in Luci), as I've got it mostly working on my end for now. When they do, I'll certainly switch to master version (like I did for long with my OpenWRT devices) and never look back.

If your problem is just wifi performance, or want to try the newest driver, best bet it to try a snapshot build from openwrt downloads site, here:
https://downloads.openwrt.org/snapshots/targets/ramips/mt7621/openwrt-ramips-mt7621-xiaomi_mir3g-v2-squashfs-sysupgrade.bin

With these daily snapshot builds you'll probably have to ssh into the router aftewards and install luci with opkg, I think (I never used those snapshot builds because when I use the master version I always compile the images myself with my preferences for my personal use, but somewhere in other more generic threads you should be able to find help if you run into difficulties).

2 Likes

Anyone have any idea on how to flash this firmware from china firmware to be global again?. AFAIK for debrick/recovery method an miwfi_r4ac_ALL_ firmware it's required because it contains a boot partition or something like that, which this updagrade firmware doesn't have, and if I try installing it directly form China UI it gets bricked again, already tried with tftp and others tool recomended for debrick, doesn't work either.

I see that the gigabit version have an ALL global firmware, that is this one here.

@araujorm Thanks for your very detailed reply :+1: You must have read my mind as have mentioned all the topics that caused me to be a little hesitant of running the current snapshot! I'd previously read about a number of issues with Luci and DSA along with MT76. I've also been reading a lot of GitHub issue history relating to MT76 and fixes are progressing impressively quickly. I'm going to gather some more structered performance test data and then switch to the latest snapshot. That way can help test and feed back on issues.

I'm comfortable in configuring by SSH if required. I may have previously misunderstood that often the latest snapshot can lead to losing access to the router, but it seems this maybe more likely where Luci is not installed or not clearing the configuration when changing between major releases?

To add to the performance issues I mentioned, I've since found that some of them were partially impacted by CPU constraint of the router.
By adding "-V" to the iperf3 command line you get visibility of the CPU load of local and remote device during testing.
By also adding "-A 0" I moved iperf3 process to run from a different core and the speed increased by about 50 Mbps.
Later I will follow up with testing between devices either side of the bridge to see if the iperf process itself is impacting the CPU load.

Without -A 0:

Test Complete. Summary Results:
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.09  sec   120 MBytes   100 Mbits/sec    0             sender
[  5]   0.00-10.13  sec   120 MBytes  99.8 Mbits/sec                  receiver
CPU Utilization: local/sender 78.0% (0.2%u/77.8%s), remote/receiver 18.3% (1.3%u/17.0%s)

With -A 0:

Test Complete. Summary Results:
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.02  sec   182 MBytes   152 Mbits/sec    0             sender
[  5]   0.00-10.07  sec   182 MBytes   152 Mbits/sec                  receiver
CPU Utilization: local/sender 65.9% (0.2%u/65.7%s), remote/receiver 25.4% (1.2%u/24.1%s)
snd_tcp_congestion cubic
rcv_tcp_congestion cubic

Yes, it's not brilliant at the moment. It's usable, but not brilliant.

Anyway, I might try to backport some few more patches, will test them and if I come up with anything useful I'll make a new build.

Just one note. If you're going to try snapshot builds, ensure you have the means for unbricking you device if anything goes wrong. The tutorials mentioned in this thread should help, but if for some reason they never worked for you before, better have a flasher at hand... Better safe than sorry, I think :slight_smile:

Best regards.

1 Like

anyone compile just latest stock Snapshot 19.0.4 + LuCi ??
i just 2 days have this router and succes install OpenWrt with araujorm build..

*btw where is Power/Off Button??

Moving away from using iperf3 directly on the routers themselves has made a big improvement.

Now getting 250 Mbps in both directions (not at the same time) through 2 identical WDS bridged routers running your latest build.

Test Complete. Summary Results:
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-10.00  sec   291 MBytes   244 Mbits/sec                  sender
[  5]   0.00-10.02  sec   290 MBytes   243 Mbits/sec                  receiver
CPU Utilization: local/sender 5.4% (1.1%u/4.3%s), remote/receiver 1.4% (0.1%u/1.3%s)

Test Complete. Summary Results:
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec   276 MBytes   232 Mbits/sec   14             sender
[  5]   0.00-10.00  sec   275 MBytes   231 Mbits/sec                  receiver

Mem: 47192K used, 75932K free, 664K shrd, 3804K buff, 11200K cached
CPU:   1% usr   0% sys   0% nic  97% idle   0% io   0% irq   0% sirq
Load average: 0.25 0.12 0.11 3/67 23195
  PID  PPID USER     STAT   VSZ %VSZ %CPU COMMAND
22932     1 root     S     1452   1%   0% luci-bwc 7
22176 21904 root     R     1232   1%   0% top
 1041     1 root     S     2244   2%   0% /sbin/rpcd -s /var/run/ubus.sock -t 30
  523     1 root     S     1256   1%   0% /sbin/ubusd
21896  1137 root     S     1152   1%   0% /usr/sbin/dropbear -F -P /var/run/dropbear.1.pid -p 22 -K 300 -T 3
    8     2 root     IW       0   0%   0% [rcu_sched]
22519     2 root     IW       0   0%   0% [kworker/2:1]
22671     1 root     S     1772   1%   0% /usr/sbin/wpa_supplicant -B -s -b br-lan -P /var/run/wpa_supplicant-wlan1.pid -D nl80211 -i wlan1 -c /var/run/wpa_supplicant-wlan1.conf -C /var/run/wpa_supplicant
 1194     1 root     S     1748   1%   0% /sbin/netifd
    1     0 root     S     1572   1%   0% /sbin/procd
 1273     1 root     S     1452   1%   0% /usr/sbin/odhcpd

I have MTD backups of stock and also files downloaded for option of TFTP recovery. Last resort is purchasing a programmer! Will take a risk on the second device as first is used for main WiFi.

Also considering having a dabble with the mesh option at some point...

I'm using snapshot-versions since weeks without problems. WPA3 works just fine :slight_smile:

1 Like

Thanks, I'll try the latest snapshot after a few beers later tonight!

do u susses install LuCi??
last night im try snapshot, but error install LuCi..

You need to ensure the device has internet access to install Luci either by using uci to configure with addr/gw/dns on existing network (if only plugging in the LAN port) or also plug the WAN port into your LAN to get the details from your existiing network...