New Xiaomi router AC2100

Is this project valid for also for Xiaomi Mi router AC2100 or just for the Redmi one?

Kinda sorta not really?

The leds are a little different. I believe the front leds have 3 colours on the Xiaomi Mi Router AC2100, and it might have amber ethernet (in addition to green, but those are handled by the switch) led to signify gigabit on the port.

Front leds are easy to figure out, Xiaomi stick all the useful information into /etc/config/xqled

Otherwise it should be 99% the same as the Redmi Router AC2100 support.

I don't own one, so that's left up to the people who do. Have fun!

1 Like

I updated and unlocked my Xiaomi AC2100 (Black One) thanks to a russian Youtube video :sleepy: about the Redmi AC2100 (White One) and everything is working fine even leds.

Could you please share the video and process maybe? Thanks in advance.

I have the exact same issue as you. I am running, tried it on 3 different computers with Win/Mac/Linux. Script just shows waiting for packets and I cannot connect to with IP being set to Have you figured out a solution? My MAC starts with 8C:53:C3 (like Percy's)

This is the Youtube Video.
There is a file inside the descritpion / comments with all folders / files contained in the tutorial.

Please be aware that on minute 5.14 it shows first a long command to paste entirely than he breaks it down maybe in order to explain how it works. Don't worry about it you just need to paste the long one.


hi @lukasz92

that seems kinda odd, doesn't it? i mean, the mir3g has the 7603 and the mir3p has the mt7615. i have both of them running openwrt (ie, i have openwrt with both mt7603 and mt7615) and they work fine. in fact, pretty much as well as the closed-source firmware we played with for a while (for mir3p... back before there was an open source mt7615 driver)...

the "closed source" drivers completely ignore the .dts file, so if mt7603 AND mt7615 aren't working for ac2100 with the opensource drivers and they're working fine with the closed source ones (and they're working fine for other devices)... then it seems like the most obvious root cause is a bug in the dts file?

at first i was assuming there was a problem with snapshot (since a lot has changed), and i "ported" ac2100 to 19.07 (untested, i don't have an ac2100) but once i saw the thing has already been added to openwrt i came back to read the forum and realized everyone seems to be having wifi problems, and then looked at the dts again :slight_smile:

first off, it's clear that the mt7603 comes first in the factory partition (i've verified it). then, looking at the other xiaomi devices, it seems like the first driver in factory is usually on pcie0. however, in the ac2100 dts, the two are switched around. (ie, 7603 is on pcie1 and 7615 is on pcie0)... i also specified the mt76 "module" to use (7603 vs 7615) explicitly, just in case that was causing problems.

i wonder if someone would care to build/test with these diffs (diff made the changes look a little more complicated than they should be)

diff --git a/target/linux/ramips/dts/mt7621_xiaomi_redmi-router-ac2100.dts b/target/linux/ramips/dts/mt7621_xiaomi_redmi-router-ac2100.dts
index f0bc1aeb96..23e46b2016 100644
--- a/target/linux/ramips/dts/mt7621_xiaomi_redmi-router-ac2100.dts
+++ b/target/linux/ramips/dts/mt7621_xiaomi_redmi-router-ac2100.dts
@@ -130,19 +130,19 @@
 &pcie0 {
        wifi@0,0 {
-               compatible = "mediatek,mt76";
+               compatible = "pci14c3,7603";
                reg = <0x0000 0 0 0 0>;
-               mediatek,mtd-eeprom = <&factory 0x8000>;
-               ieee80211-freq-limit = <5000000 6000000>;
+               mediatek,mtd-eeprom = <&factory 0x0000>;
+               ieee80211-freq-limit = <2400000 2500000>;
 &pcie1 {
        wifi@0,0 {
-               compatible = "mediatek,mt76";
+               compatible = "pci14c3,7615";
                reg = <0x0000 0 0 0 0>;
-               mediatek,mtd-eeprom = <&factory 0x0000>;
-               ieee80211-freq-limit = <2400000 2500000>;
+               mediatek,mtd-eeprom = <&factory 0x8000>;
+               ieee80211-freq-limit = <5000000 6000000>;

i threw together a github repository. it has the dts changes for above, and also the (slightly more involved) changes in case people want to build 19.07 for this device (i'd recommend it, since who knows how stable snapshot is at the moment....) that's under the openwrt-19.07 branch.

EDIT: based on @namidairo 's comment, it seems unlikely that this patch really will solve anything. just in case, and since i already built it, i uploaded the binaries as well. (under "releases")

i'll also compile and upload "regular" (unswapped pcie slots) 19.07 in case that turns out to work better.

1 Like

To my knowledge, it's based on the order of where they are placed in the pci slots, not in which order they came in the factory partition? If it were wrong you'd have a very unhappy mt76 which would complain about getting the wrong eeprom provided for the device.

00:01.0 PCI bridge: Device 0e8d:0801 (rev 01)
01:00.0 Unclassified device [0002]: MEDIATEK Corp. Device 7615
02:00.0 Network controller: MEDIATEK Corp. Device 7603

As for the MT7603 and the weird droppyness, I have noticed that as well.


yeah of course it has to do with the pcie slots... i'm just going on partial information here (really based on what one user has been pm'ing me about)

yeah something like that. in fact that's what i had been assuming was happening.

so: 7615 works fine and 7603 has "droppyness" but otherwise works fine? i'll stop now then.

That's been my experience so far. I've delegated 2.4 to a couple of my older routers for now. (It's only 2 stream 11n, most of everything from the last decade can pull that off)

There seems to be an open mt76 issue on this?

I have another openwrt router running in client mode connected on 5ghz though, that seems fairly solid.

Are the instructions on still valid and complete?
I'd prefer this over a 12 minute video in Russian.

After bridging it and updating it to eth9 (my interface) it fails at the following point:

Waiting for packets
Client->Server   |   Discovery Initiation
Server->Client   |   Discovery Offer
Traceback (most recent call last):
  File "", line 183, in <module>
    sniff(prn=packet_callback, filter="pppoed or pppoes", lfilter=isNotOutgoing)
  File "/usr/local/lib/python2.7/site-packages/scapy/", line 972, in sniff
    sniffer._run(*args, **kwargs)
  File "/usr/local/lib/python2.7/site-packages/scapy/", line 925, in _run
  File "/usr/local/lib/python2.7/site-packages/scapy/", line 47, in on_packet_received
    result = self.prn(pkt)
  File "", line 73, in packet_callback
    PPPoETag(tag_type=Host_Uniq, tag_value=host_uniq))
File "/usr/local/lib/python2.7/site-packages/scapy/", line 140, in addfield
    return s + struct.pack(self.fmt, self.i2m(pkt, val))
  File "/usr/local/lib/python2.7/site-packages/scapy/", line 1380, in i2m
    f = fld.i2len(pkt, fval)
  File "/usr/local/lib/python2.7/site-packages/scapy/", line 938, in i2len
    return len(x)
TypeError: object of type 'NoneType' has no len()

Looks like Host_Uniq is not defined, is this something I need to configure manually or any suggestions?
Edit : not that I guess, I added debugging for all fields and all I got was

Waiting for packets
Tag type:: 
Tag value:: 

Tag type:: 
(... repeated)

and then back to Client->Server   |   Discovery Initiation
Server->Client   |   Discovery Offer


I wrote a guide for the black cylinder because I want to help OpenWrt newbies (like me). The following steps worked perfectly for me, but I'd be happy if someone with more experience can make corrections / suggestions if needed:

Hope it helps someone


Wow that just literally solved my problem immediately :star_struck:
That diagram on how to bridge was what I was doing wrong

Edit: Erh wait actually I spoke a little too soon, I'm still getting the same error but perhaps I'm getting closer now as it's not showing the same in the UI ...

Good to hear, please let me know if you could set up OpenWrt successfully with my guide :blush:

Getting closer, I think there's a few "bugs" in the pppoe script that cause premature termination if it's not in the correct state, I'll add some suggestions if I get it all finished successfully.


Thanks for your amazing guide.
Here's some notes:

  1. It will prematurely die if it's not in the expected state during PPPoe initialisation : this isn't a problem, just continue with it
  2. I couldn't get it to work with python2, only python3, though this may not have been related and you use python3 in your guide anyway but maybe worth clarifying
  3. I missed cloning the repo so I had no busybox but that was my fault :smiley:

One issue remains, I hope it's not too serious .. there's no web interface or anything running on port 80.
I can SSH in so I assume I'm okay but is it supposed to be running the web UI by default?

Regarding your points:
1: Not sure what you exactly mean
2: Python3 is explicitly listed in the requirements
3: :smile:

The web interface should be running at whatever IP shows as router in your network settings (no port or anything needed). For me it is running at

  1. In your guide, the first screen you show in the web interface is not the same as I had with a brand new installation : there's a couple of screens before it. If the pppoe script is running at this point (before your first screen) it will crash when the packets are received. It's not a fatal error so you can keep going but this was one my initial hurdles.
  2. It's missing the following step at the point when it says you should be able to access it via the web interface (update: this is probably because I have the wrong image?)
opkg update
opkg install luci

At this point luci is not installed so that's why no web interface I guess =)
So just needs to remove the comment saying you should be able to access it via the web at that point.

Edit : it's connect but incredibly unstable, it holds a connection for about 4 or 5 seconds then loses it for 30 seconds or so, I can't even finalise install luci. Anyone have any idea what might be causing this or where to look?

Edit2 : I realised perhaps this is because I used the binaries from instead :confused: I guess they're not stable perhaps?
Any way of changing this without repeating the whole process?
Do I just need to scp and

mtd write xiaomi-router-kernel1.bin kernel1
mtd -r write xiaomi-router-rootfs0.bin rootfs0

Or is there any danger in doing this at this point?

that's odd.. like i said, i'm going on one user's pm's and some posts in this forum (such as by @lukasz92) claiming wifi doesn't work well...

anyway, the user who had pm'ed me about wifi issues reported that the 19.07-based build i uploaded (a few hours ago) apparently works for him... but apparently i botched the wan/lan ports, so i'll fix that and give it another shot. in case anyone else is having wifi issues, they might want to try it out...

1: There should only be one terms and conditions screen before the screenshot which redirects to It's already written in the guide to just click on the blue button but I made it a bit clearer.
2: luci is only installed on that image provided in the repo. Also made some changes in the guide to specify that more

Not sure about the write, but if it goes wrong it should be no problem to go back to stock firmware and try again with the recovery tool.