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

This. Doubts about OpenWrt usage, not device specific, please put on a new thread.

In any case, I wouldn't mess much with init.d for what you asked, you should be able to override the MAC address using the web interface, as per attached screenshot:
Selection_20200803(001)

Every interface has that option, just note that one thing is the "wifi interface" that you configure in the Wireless section, and another is the "Interfaces" section: one must be refered by the other, but the mac address is changeable in the "Interfaces" section. I never tried to change it from there, but it should work and become persistent after a reboot.

1 Like

Sorry for out of topic, but overide Mac address not work on this

Thanks for this, I've must have tried 5 differents images multiple times throughout the past months, all resulting in bricks for some reason. This worked.

Some notes:
I could not easily wget or curl your github assets on the stock Xiaomi firmware, I downloaded and hosted them somewhere where I could use wget or curl.
There was no partition named kernel, I flashed the image to firmware which worked:

mtd -e firmware -r write openwrt-ramips-mt7621-xiaomi_mir3g-v2-squashfs-sysupgrade.bin firmware

Thanks for your work!

1 Like

Hello,
Back again after few months with flashed my Mi router 4 flashed with openwrt ( Firmware Version:
OpenWrt 19.07.2 r10947-65030d81f3 / LuCI openwrt-19.07 branch git-20.057.55219-13dd17f).

Now, I'd like to update to the last stable version.
What procedure has to be followed please ?

Thanks again !

Hello, I am wondering to expand EEPROM storage with Arduino SD Card shield. Since Arduino SDCard Shied and R4AG is using same protocol for ROM interface (SPI protocol) *CMIIW.

I think it might works. Any thought?

hello, thank u very much for the Steps.

i flowed every steps, but i got nothing from ttfpt, i also actived the windows function for that, but it still doesn't work.

i also tried 192.168.0.xxx, 192.168.1.xxx and 192.168.31.xxx, it came the same.

background, ich booted the OpenWrt and it startet to restart without ending.... that why i wanted to save it

could u pls give me some advice what i should do?

hoping for ur info.
thanks a lot.

Hello all, I want to flash the image that build using image builder, master branch, however when try to flash it, there is notice as follow:
"Device xiaomi,mir3g-v2 not supported by this image Supported devices: xiaomi,mir3g-v2 - Image version mismatch: image 1.1, device 1.0. Please wipe config during upgrade (force required) or reinstall. Reason: Config cannot be migrated from swconfig to DSA (early adopters with DSA already set up may just force-flash keeping existing config) Image check failed.

The uploaded image file does not contain a supported format. Make sure that you choose the generic image format for your platform."

it is ok to do the FORCE UPGRADE the firmware?
If after I upgrade it, can I revert back to v19.07 branch? (sorry, I am new to this openwrt, just start trying to builde image last week for my old tplink wdr3600, and now want to test it with mifi 4A gigabit)

Thanks in advance and sorry for my english, i am from Indonesia.

Yes, but you must delete the existing configuration over the upgrade (sysupgrade -n -F <sysupgrade-image.bin>), as the networking configuration differs between 19.07.x and master.

1 Like

thanks for the peeps out there who makes this possible having it much easier to flash the router with using the OpenWRTInvasion, I flashed this router to OpenWRT and turned it to a SSID-VLAN AP kind of thingy.

the only hardship I deal with this router is configuring the switch since im using VLANs to pair it with each SSID on their own network (managed by pfsense), one thing for sure is OpenWRT switch configuration really hates mixing untagged and tagged configuration on single port, you can only do either single Untagged port, or multiple tagged vlan, you cant mix it with the usually I do on most AP which is untagged for management and tagged for the actual SSID-VLAN pairing which works fine on Tomato firmware routers that I have already working.

but anyway it works really well now (cross fingers).

Thanks for your reply, will flash it tonight

@hoddy thank you for your awesome guide on youtube! As a complete newbie to Linux Ubuntu I found your video extremely helpful on getting openwrt installed especially your debricking tool thank god, I had 3 bricks trying to install @araujorm and Byte builds not sure why it wouldn't work with those I have a feeling when I done the curl via telnet it didn't download the file properly for either of them(total 670ish each compared to Zorro at 4500ish) I used curl https://github.com/araujorm/openwrt/releases/download/mir4ag-19.07-20200722/openwrt-ramips-mt7621-xiaomi_mir3g-v2-squashfs-sysupgrade.bin --output firmware.bin is that correct or not?

Anyway thanks to Zorro build I got openwrt installed on the 4th time thankfully, only problem is I can't see openvpn settings on this build so I'm guessing it might not have them?

So @hoddy now that I have Zorro's build installed can I easily flash another build to it? Like araujorms with openvpn, is this something I can do straight on the router now? Or do I have to do it with Ubuntu terminal?

What is your favourite build to use at the moment with openvpn?

Massive thanks to absolutely everyone involved in making this possible

1 Like

installing original xiaomi FW from openwrt with MIWIFI Repair tool its work

Hi everyone!

First post, usually am more of a lurker and I am able to find my solutions with help others already gave without bothering anyone, there is always an exception, I have bricked my R4A (giga - global) router, it was quite fast to do and I don't know what is going wrong now.

Bought it yesterday already knowing I would flash it, came home, plugged it, applied exploit and flashed, I only saw the stock firmware for half a dozen seconds

I used OpenWRTInvasion and could get access to exploit, from there I used telnet to flash OpenWRT firmware, rebooted and could ssh into it,no issue, but I couldn't install Luci, so in this page I saw some steps to flash newer image by ssh, which I did and after reboot I could install Luci, even installed openvpn and configured it nice.

All was going nice and smooth and I noticed the bad 5G wifi, so I tried to play a bit with it but no success.

I saw some numbers in this topic showing that Padavan was having a slight better performance with 5G wifi but from what I understood it needs to be flashed from stock, from there I also thought well why not give a shot to the stock one too.

So I followed the TinyPXE process, all went fine but after reboot I couldn't get into router page, the status LED stayed in fixed orange and didn't turn blue. After 3 reboots still the same. So I did the process again, and result kept the same.

I then used the process in Linux with bootpd and also even installed a Chrome extension for chinese VPN to be able to download the files from MiWiFi website and i also used MIWIFIRepairTool.

Whatever it was with TinyPXE, Linux or Mi repair tool, I could upload bin file fine and process looked proper, they were all doing what they were supposed to, but result is always reboot when it should go blue.

I went back and forth through the 1072 message of this topic and can't find any related post, have I done something to my router? Have I somehow messed up the bootloader? If so, should it not even accept the image?

From what I can understand it is now stuck in some boot loop, it keeps rebooting itself everytime around the time that the LED supposedly should turn blue.

The flashing process seems to go as expected since the orange LED blinks when set to bootp, keeps blinking while bin file is being sent, once sent it goes to fixed orange and once flash is done it blinks blue. These steps happen each time I try to flash the chinese stock ROM no matter the tool.

If I try to flash any other image the router starts blinking purple as soon as it finished receiving the image and tries to flash it, which is what makes me think that the process is correct when flashing chinese stock.

Ping requests are getting response from router IP but very inconsistent, seems like something broke but I don't have enough knowledge to understand what did and how to fix:

$ ping 192.168.31.1
PING 192.168.31.1 (192.168.31.1) 56(84) bytes of data.
64 bytes from 192.168.31.1: icmp_seq=1 ttl=64 time=3.41 ms
64 bytes from 192.168.31.1: icmp_seq=2 ttl=64 time=0.489 ms
64 bytes from 192.168.31.1: icmp_seq=3 ttl=64 time=0.502 ms
From 192.168.31.21 icmp_seq=4 Destination Host Unreachable
64 bytes from 192.168.31.1: icmp_seq=18 ttl=64 time=0.434 ms
From 192.168.31.21 icmp_seq=26 Destination Host Unreachable
From 192.168.31.21 icmp_seq=27 Destination Host Unreachable
From 192.168.31.21 icmp_seq=28 Destination Host Unreachable
64 bytes from 192.168.31.1: icmp_seq=29 ttl=64 time=0.605 ms
64 bytes from 192.168.31.1: icmp_seq=30 ttl=64 time=0.492 ms
64 bytes from 192.168.31.1: icmp_seq=31 ttl=64 time=1.94 ms
64 bytes from 192.168.31.1: icmp_seq=32 ttl=64 time=0.405 ms
64 bytes from 192.168.31.1: icmp_seq=33 ttl=64 time=0.411 ms
64 bytes from 192.168.31.1: icmp_seq=34 ttl=64 time=0.559 ms
64 bytes from 192.168.31.1: icmp_seq=35 ttl=64 time=0.399 ms
64 bytes from 192.168.31.1: icmp_seq=36 ttl=64 time=0.862 ms
64 bytes from 192.168.31.1: icmp_seq=37 ttl=64 time=0.518 ms
64 bytes from 192.168.31.1: icmp_seq=38 ttl=64 time=0.509 ms
64 bytes from 192.168.31.1: icmp_seq=39 ttl=64 time=0.396 ms
64 bytes from 192.168.31.1: icmp_seq=40 ttl=64 time=0.480 ms
From 192.168.31.21 icmp_seq=41 Destination Host Unreachable
From 192.168.31.21 icmp_seq=45 Destination Host Unreachable
From 192.168.31.21 icmp_seq=51 Destination Host Unreachable
From 192.168.31.21 icmp_seq=57 Destination Host Unreachable
From 192.168.31.21 icmp_seq=58 Destination Host Unreachable
From 192.168.31.21 icmp_seq=61 Destination Host Unreachable
From 192.168.31.21 icmp_seq=62 Destination Host Unreachable
From 192.168.31.21 icmp_seq=63 Destination Host Unreachable
64 bytes from 192.168.31.1: icmp_seq=64 ttl=64 time=0.470 ms
From 192.168.31.21 icmp_seq=72 Destination Host Unreachable
From 192.168.31.21 icmp_seq=73 Destination Host Unreachable
From 192.168.31.21 icmp_seq=74 Destination Host Unreachable
64 bytes from 192.168.31.1: icmp_seq=75 ttl=64 time=0.871 ms
64 bytes from 192.168.31.1: icmp_seq=76 ttl=64 time=0.495 ms
64 bytes from 192.168.31.1: icmp_seq=77 ttl=64 time=2.92 ms
64 bytes from 192.168.31.1: icmp_seq=78 ttl=64 time=0.389 ms
64 bytes from 192.168.31.1: icmp_seq=79 ttl=64 time=0.461 ms
64 bytes from 192.168.31.1: icmp_seq=80 ttl=64 time=0.618 ms
64 bytes from 192.168.31.1: icmp_seq=81 ttl=64 time=0.526 ms
64 bytes from 192.168.31.1: icmp_seq=82 ttl=64 time=0.693 ms
64 bytes from 192.168.31.1: icmp_seq=83 ttl=64 time=0.653 ms
64 bytes from 192.168.31.1: icmp_seq=84 ttl=64 time=0.530 ms
64 bytes from 192.168.31.1: icmp_seq=85 ttl=64 time=0.494 ms
64 bytes from 192.168.31.1: icmp_seq=86 ttl=64 time=0.548 ms
From 192.168.31.21 icmp_seq=87 Destination Host Unreachable
From 192.168.31.21 icmp_seq=88 Destination Host Unreachable
From 192.168.31.21 icmp_seq=89 Destination Host Unreachable
From 192.168.31.21 icmp_seq=90 Destination Host Unreachable
From 192.168.31.21 icmp_seq=94 Destination Host Unreachable
From 192.168.31.21 icmp_seq=95 Destination Host Unreachable
From 192.168.31.21 icmp_seq=97 Destination Host Unreachable
From 192.168.31.21 icmp_seq=98 Destination Host Unreachable
From 192.168.31.21 icmp_seq=99 Destination Host Unreachable
64 bytes from 192.168.31.1: icmp_seq=100 ttl=64 time=0.446 ms
^C
--- 192.168.31.1 ping statistics ---
103 packets transmitted, 30 received, +24 errors, 70.8738% packet loss, time 104215ms
rtt min/avg/max/mdev = 0.389/0.750/3.411/0.705 ms, pipe 4

I thought it might be an issue with messed up MAC address but I get this output when poking it:

$ ip route list
default via 192.168.31.1 dev eno1 proto dhcp metric 20100 
192.168.31.0/24 dev eno1 proto kernel scope link src 192.168.31.21 metric 100 
$ ip neigh
192.168.31.1 dev eno1 lladdr 54:48:e6:xx:xx:xx REACHABLE

Then after a few seconds:

$ ip neigh
192.168.31.1 dev eno1  INCOMPLETE

The MAC address is not showing as 00:00:AA:BB:CC:DD and is showing a proper MAC vendor prefix...

Beijing Xiaomi Mobile Software Co., Ltd

MAC prefix: 54:48:E6
Vendor name: [Beijing Xiaomi Mobile Software Co., Ltd ]
MAC range: 54:48:E6:00:00:00 - 54:48:E6:FF:FF:FF
Block Size: 16777215 (16.77 M)

It's 7PM and I have been fighting the router since 11AM, sometimes we have to accept the defeat and ask for help, so here I am :stuck_out_tongue:

Would anyone by any chance have a slight idea of what is going on here and how I could eventually fix it?

Many Thanks!

Thank you very much! So from your current build you can use the system upgrade function in luci to move to byte or araujorms builds always check your checksums before doing so to ensure they haven't been corrupted on download.

As for install of other tools you can use Luci's software page, a good rule of thumb is if the software has luci in the name it will normally have the web gui for that package so you can configure it in luci (e.g luci-app-openvpn will give you openvpn in luci) (Make sure you click "update list" first).

If you're enjoying the new terminal access you could ssh to the router:
ssh root@192.168.1.1
then install a package with something like:
opkg update
opkg install luci-app-openvpn

enjoy!

1 Like

So I've heard of similar, it might be worth checking that the stock firmware images you have arent corrupted on download, try redownloading again a fresh version and retry. Also once the image has been uploaded to the router by whichever tool leave it for 30mins perhaps an hour before reboot if you're having issues. Thought the image gets uploaded quite quickly the actual decompress and install takes a lot longer.

From your ping log I'd agree it seems to be stuck in a boot loop, I definitely wouldn't say its dead I've known them to come back from worse. The MAC thing is normal at boot, the TFTP at boot defaults to 00:00:AA:BB:CC:DD.

Thanks for all your help 5th time lucky I'm finally on araujorns

1 Like

Hi hoddy,

Thanks for the reply, I already downloaded all the mirrors and reposts of the firmware available along the web, or at least it feels like it.
I was a bit lazy in debricking the router with the posts at beginning of topic, so I was being a bit careful with what I was doing, then I saw your posts and Zorro and the tricks you guys found to make it much simpler and also nuqz post showing how easy it is in Linux, so I thought OK if it's so easy to debrick then let's go and play with the router and try all the images that exist, well, I only got to try one and bricked it in a way I can't recover lol, great.
I downloaded from your website too, compared checksums and all.

$ sha256sum TinyPXE4A.zip
bddbe28e11bd7145e9ee1aa40c17f2256def64eec3ec46070bc34f172f1debb9  TinyPXE4A.zip
$ sha256sum test.bin
07d3cead22e3c4fbe98eec29de5d5bea8dad12ade931179972ee56d2ac249060  test.bin
$ sha256sum miwifi_r4a_firmware_72d65_2.28.62.bin
07d3cead22e3c4fbe98eec29de5d5bea8dad12ade931179972ee56d2ac249060  miwifi_r4a_firmware_72d65_2.28.62.bin

Which in theory should be the file for my router:

Yesterday after your post I left it 40min, same result, so then I left it for 1h40min, that should give it time to flash it 10x but issue still persist, then I gave up and went to bed.

I came to think it might be some component that took early retirement which makes the router reboot itself every 10s but then the router can receive and flash the stock firmware and stay like that for 1h without a single reboot, so the components should be fine.

I see everyone saying they did it on first try and I have been fighting the router for more than a day...
¯_(ツ)_/¯

Is there another version of stock that is not 2.28.62? Maybe my router wants another one.

I don't know where to turn anymore :confused:

Thanks!

1 Like

Im not sure, you could download the stock direct from the MiFi website, it should be the same as the one on my site but it may be a newer version. Last result would be to get a CH341A Programmer and reflash the chip, not exactly an easy solution but definatly doable, you will need a flash dump from the 4A i think a few have posted theirs on this forum and at the begining you will find a guide to using the CH341A. If you struggle I can dump my 4A's flash for you.

Yeah I already downloaded stock from everywhere, even managed to put my hand on older version of stock, if it might interest anyone I put it here (had to go again under Chinese IPs to be able to grab it, so if anyone wants it we can spare the trouble)
https://anonfiles.com/F7MbbbPeo7/miwifi_r4a_firmware_51508_2.28.38_bin

From: https://bigota.miwifi.com/xiaoqiang/rom/r4a/miwifi_r4a_firmware_51508_2.28.38.bin

$ sha256sum miwifi_r4a_firmware_51508_2.28.38.bin
77b4792b6641ee5f4877108cccc6660d1f0d4296d573563c877c24083fcafdf5  miwifi_r4a_firmware_51508_2.28.38.bin

Anyway I think I kind of have pinpointed what happens.

So we have the usual ping to router IP that replies then stops replying then replies again and so on:

$ ping 192.168.31.1
PING 192.168.31.1 (192.168.31.1) 56(84) bytes of data.
64 bytes from 192.168.31.1: icmp_seq=15 ttl=64 time=1.08 ms
x7
64 bytes from 192.168.31.1: icmp_seq=23 ttl=64 time=0.419 ms
ping: sendmsg: Network is unreachable
x22
ping: sendmsg: Network is unreachable
64 bytes from 192.168.31.1: icmp_seq=54 ttl=64 time=0.599 ms
x5
64 bytes from 192.168.31.1: icmp_seq=60 ttl=64 time=0.552 ms
and so on
--- 192.168.31.1 ping statistics ---
126 packets transmitted, 23 received, 81.746% packet loss, time 832ms
rtt min/avg/max/mdev = 0.419/0.756/5.119/0.938 ms

Then I tried pinging miwifi.com (with no other network interface enabled than LAN to router of course) I get replies, so the router is up and running and is already handling hostnames:

$ ping miwifi.com
PING miwifi.com (192.168.31.1) 56(84) bytes of data.
64 bytes from XiaoQiang (192.168.31.1): icmp_seq=1 ttl=64 time=0.417 ms
x6
64 bytes from XiaoQiang (192.168.31.1): icmp_seq=8 ttl=64 time=0.444 ms
ping: sendmsg: Network is unreachable
x22
ping: sendmsg: Network is unreachable
64 bytes from XiaoQiang (192.168.31.1): icmp_seq=38 ttl=64 time=0.641 ms
x5
64 bytes from XiaoQiang (192.168.31.1): icmp_seq=44 ttl=64 time=0.573 ms
ping: sendmsg: Network is unreachable
and so on
--- miwifi.com ping statistics ---
113 packets transmitted, 24 received, 78.7611% packet loss, time 595ms
rtt min/avg/max/mdev = 0.417/0.547/0.642/0.064 ms 

When I ping 8.8.8.8 I even get a couple responses before it cuts off if I plug a WAN cable.

I also see that WiFi enables and I can see it on my phone and laptop, with laptop it takes too long to refresh the list then connect, by the time the PC tries to connect the router is already gone rebooting, but with phone i do have time to connect to WiFi network and that's where it makes me think I think what brings the issue I am facing.

(had to add this as a screenshot from the editor preview pane as I cannot attach more than one image due to my account status)

So it makes me think that it's something related to WiFi settings that make the router somehow reboot itself, but i have no clue what it is.

Any change I might have applied with OpenWRT is supposed to be gone and not interfere in any way once the router gets flashed with stock ROM, right?

I am a bit tired of it for now and will probably leave it be for a couple days until my brain is not saturated with it anymore, then I might try to open the router and see if I can physically disable WiFi and see what happens.

This makes no sense, but it's kind of what my IT life as been since the first days so I am not that shocked lol.

Edit:

Hum, now that I have actually paid a bit more attention I see that the sticker on bottom of router says the SSID should be "Xiaomi_[last 4 digits of MAC address]" and the SSID broadcasted by the router now is "Xiaomi_[last 4 digits of MAC address]_FC2E".
I have no FC:2E anywhere on the mac address of the router, where did it got that from? Could it be because I insisted with so many different images and dumps that somehow some wrong information stuck?

If I flash the SPI chip with someone else dump will I not lose the hardware related info? Or does the firmware calculate the values "on the fly" on a router basis from its hardware?

Yeah, if you've debricked then OpenWrt should be long gone and not affect you.

Not sure why this would be, might be a quirk of the firmware image you've got?

Yes, you will, at least the MAC addresses someone posted in this thread a long time ago how to change it though basically you use a hex editor on the flash file and replace the values with your own if you know them.

I assume you've tried the debrick method a few times and always get the same result?