Hi chaps, welcome and thanks for watching.
Here is the breakdown of this Episode. Please use the chapter markers if you
want to skip or fast forward. We will have a closer look at the Xiaomi
Mirouter 4A Gigabit edition today. We‘ll test the Ethernet switching and routing
performance plus the Wi-Fi performance, first with the stock firmware and then with OpenWrt.
But before we flash the device with OpenWrt we will have a look at some – well let‘s call it
specifics of the original firmware. Stay tuned. (Jingle) In my last video I compared three routers
and how they perform with OpenWrt. Many of you left me comments on youtube –
thanks for that – asking if I would want to have a look at the Xiaomi Mirouter 4A (I hope
that I do pronounce this correctly – leave me a comment ;-) ). This device costs roughly 30
Dollars and has Mediatek Hardware, so it should be the perfect fit as a home router. So – I was
curious myself and hence I bought one on Amazon. That means that I am not in any way
affiliated with Xiaomi – they did not provide me with the device and they are
not paying me to do these tests in any way. First look at the device – it‘s quite small,
really flat if I compare it for example to the Archer C7 here – it has 4 antennas and it has
three Gigabit ports, two for the LAN and one for the WAN. It does not have any USB ports.
There are no wall mounting holes or anything so either you put the device on a table or desk or
shelf or you need to 3D print clamps or the like if you want to wall mount it. It‘s really small
or rather flat – will it have enough juice to provide Gigabit connection ? Let‘s not judge
a book by its cover but see for ourselves. Cool, so let‘s have a quick view at the
Installation and the user interface. When you plug the router in for the first
time, then it will act as a DHCP Server on the LAN interfaces and will be reachable on
the 192.168.31.1 address. The first thing that it asks you to do is that you select your region
and agree to their terms and conditions. I suggest you read those terms and conditions. It
will become clear why later in the video. Once I have read and accepted the conditions
I will then have to put in a password for the Wifi and web interface which will be printed
out in clear text on the next screen. So just make sure that nobody is watching
over your shoulder when you do this. The router reboots and once I reconnect
to its IP address in the web browser, I am greeted with this QR code which would let
me download an app to access the router remotely. I am not doing this, I just want to use the web
interface. Here you can do stuff like manage the Wi-fi, some very basic network settings, activate
Quality of Service, DHCP and dynamic DNS or VPN. The user interface is really slim and down to
earth with the most basic settings here. One thing intrigued me though – look at the URL –
that does look like OpenWrt. Does the router already have OpenWrt installed ? we‘ll see
later. Before that – let‘s get shell access. The documented way of installing OpenWrt on
that device is actually to use an exploit called OpenWrtInvasion which you can get
from Github – link is in the description. The easiest way to use this is to run it in
docker. So let‘s do that quickly. The container is built and when I run it, it asks for the
router‘s IP address and the session token which I can just copy from the Web Interface. Once the
exploit has ran then we can telnet into the router and do stuff there. Let‘s first do the speed tests
and then we will look around a bit on the device to see what‘s under the hood. Guys, if you want to
see a more detailed video on the flashing process then please check out that video of fellow
youtuber hoddy who also wrote a guide and more importantly pre-packed the pxeboot utility
in order to unbrick the router on his blog. Please do show him some love and give
his video a like! Many thanks guys! The test scenario in my last video consisted
of a combination of htop running on the device itself in order to monitor the impact
on CPU on the router and iperf or iperf3 from the outside in order to measure throughput.
We don‘t have htop on this device but we have top which is not so colorful but it will do the job.
So let‘s go. First scenario – I switched off the DHCP Server on the router and then connected
both LAN interfaces to my LAN on one side and to my laptop on the other. Now I can
run a speed test from one LAN port to the other which should not trigger routing
but rather happen on the switch hardware. As you can see we get quite decent performance
here. Top shows no CPU load, just as expected- there is switch hardware inside the device.
That‘s good. Let‘s do the next test. In order to test routing performance we will
run the speed test between the LAN interface and the WAN interface. Going from one subnet to
another will force the device to use the routing functionalities. Iperf3 shows really decent speed
figures here and – no CPU load. So the device must be using hardware offloading. Ah ! That
makes we want to test quality of service – you remember ? On OpenWrt we can currently not
use Qos / SQM / Smart queuing and Quality of service – together with Hardware offloading –
it‘s either the one or the other (at the time of making this video, that means in November
2021). But let‘s do that after the Wi-Fi tests. The device can do 80 MHz channel width in the
5 GHz band, that means a theoretical maximum speed of 866 Mbits. So realistically I would
expect something around the 500 to maybe 600 Mbits speed here with one client. Here is the test
scenario explained quickly again. One Server is running iperf3 on ports 5201 and 5202. My iPhone
is running iperf3 in client mode and is connecting to one of those server instances and my laptop to
the other one. First with one device. As you can see we do get I‘d say a quite stable 400 to maybe
500 Mbits – In the beginning of the test I have been moving around with the phone. Not too bad.
The interesting thing here is that the device only shows roughly 20% CPU usage. Let‘s add the second
WiFi client. The impact is immediate and obvious. The total performance drops to something like
300 Mbits, 200 on one and below 100 on the other client. Not so good but still OK given that we’re
pumping a constant data stream over both clients. Cool – so much for the tests with stock
firmware. I am curious to see how we will perform with a full OpenWrt install –
given that there will be a different environment from a Linux Kernel and
driver perspective. But before we do that let‘s look around a bit on the device
now that we have this nice shell access. The first thing I did before I implemented
the exploit was running nmap against the router in order to see which ports are open.
Open ports on a router can be red flags for a network administrator as every single application
that has an open port could potentially increase the vulnerability of the device. From the LAN
side we can see a lot of open ports here – I am curios to see what they do. From the WAN
side all ports seem to be closed – that’s OK. Once I implemented OpenWrtInvasion it does of
course show additional open ports, namely tcp ports 21 for FTP, 22 for ssh and 23 for telnet.
Let’s telnet into the router and first query some basic variables. The proc file system will
be our friend here. Also there are a couple of tools like uname, netstat and lspci which can give
us further information. First the Kernel version. It looks like the router is running on a
Version 3 linux kernel. Lspci shows 4 devices, that will be the Ethernet cards – apparently
there are two of them – then the 2.4GHz WiFi and the 5 GHz WiFi. That’s it. Let’s see which
modules we have loaded. We can see the usual modules like the drivers for the Mediatek hardware
but also some other ones like Voip / SIP support. Let’s check the running processes. There are a
couple of processes here that you would not find on a standard OpenWrt installation. We’ll see in a
second what they do. Also I can see here that the router pings an api host every 2 minutes. that’s
actually an Amazon cloud hosted instance here. Next let’s see the listening ports here – whoah –
loads of open ports and applications listening – let’s see if there are established
connections to the internet. In other words, let’s see if the device is phoning home.
Big surprise – there seems to be an active MQTT connection to this address here.
Looking it up with nslookup it shows yet another Amazon cloud instance. I have
also tried to subscribe to that MQTT server with mosquitto_sub – which works but yields
no result if I listen to the hash topic – so at least not everyone can listen in to the
traffic that my router sends to that address. But what does it use it for ? Presumably
this is the communication channel to the App which the router starting page invited me
to download. Let me explain that quickly. These days people expect Consumer hardware to be
accessible via an app on their mobile phones. Be it checking the webcam at home or checking
or adjusting the temperature of a thermostat or – like in this case – the WiFi router. In
technical terms this is quite easy to achieve when you are in the same network, for example
if you are at home and you are in the home WiFi. But people expect this to work everywhere
in the internet. The problem is that it is not easy to get into your home network from
the outside. That’s what firewalls are for. You could of course use a technology called
port forward which would mean open a small window on your firewall but this is quite hard
to secure – it requires strict firewall rules, additional authentication and dynamic DNS in order
to find the home network from the internet. So how to solve this dilemma? Vendors have started to
attach cloud based services to their products. The way this works is that rather than trying to
go into your network from the outside the device which you want to control phones home – or in
technical terms it connects to a well known instance in the internet. The app which they
provide to you connects to the same instance. It is kind of a proxy or relay configuration.
Both connections are outbound, hence no hindering firewall. You do something in the app, send it
to that cloud server and that server uses the established connection to relay the command.
So is this a problem ? And if yes, why ? Well, in my personal opinion it’s not a problem at all
as long as you are aware of it and you consent to it. In other words – you need to be OK with
the fact that someone else controls your device. If you know all the facts – like WHO is using
your data for WHAT and HOW LONG they are using it and you make an educated decision that this
is what you want then that’s totally OK. But wait – I am a citizen of the European Union
and I am protected by the General Data Protection Regulation – the GDPR. That means that I have
rights here. They should have told me about all this. Have they ? Yes – they have! You remember
the very first screen when I set this router up ? It asked me to agree to their User Agreement
and Privacy Policy. Luckily I kept a copy – and – screening it – yes – they tell me – Marc, we are
collecting your personal information – and here is how we use it. They also do have a representative
in the European Union who I can contact if I have any concerns. Guys, I am not a lawyer, right
– this is a tech channel. Just be aware that if you are using this router with stock firmware
then you are transmitting data to them. Right ? Looking around I found a couple of things like
that messaging task which connects via MQTT to the AWS instance, the constant ping, some
firewall rules which would open ports on the WAN side – and of course – yes, this router is
running a heavily customized version of OpenWrt – we can for example use the uci command
to query the OpenWrt config data. One thing that has particularly intrigued me is
the fact that the router can do quality of service QoS with apparently 0% CPU utilization.
Actually there is a lua script running which seems to be responsible for this. I might
have a closer look at that in the near future. OK, I do not want my router or webcams
or thermostats or any device in my home to be accessed or controlled by any
3rd party – hence I will go ahead and flash the device with the real
thing – with fully fleshed OpenWrt. Right after this – CALL TO ACTION – I need you to
get involved please. I would like to hear from you if you are using cloud-controlled devices
like IOT devices (thermostats, cameras etc.) and if you do have any concerns
about security or privacy. I would also love to hear from you what your
take is on having a router being controlled over the internet or by a 3rd party. Please
do leave me a comment. Many thanks guys ! Before I flash the router though I want
to take a backup of the existing firmware. Usually I would do this on a USB stick. Since
the device has no USB port, I need a different way of pulling an image of the firmware here.
I could mount a volume on my NAS or over NFS or write into a file on the temp file
system and then download it with ftp but ad hoc I can also just use nc or netcat
and pipe the output of the dd or cat command to a network socket on my local host. Let
me show you an example of how this works. On the router I do something like for example
just print hello or output a text file and then I pipe it over to nc which expects a counterpart
on this IP address on port let’s say 10,000. On my workstation (which has the IP address
which I just specified on the other end) I let netcat listen on that port 10,000 and –
tadah – the content is sent over from the file to my local workstation over the network. So I’ll
do that with the content of the MTD block devices which do actually contain the firmware
and write the output into a file. If I have something to generate hashes like
md5 or sha256 I can even verify the content on both sides and make sure that I have an
accurate copy. In this case the checksum will always vary on the mtd7 device because
this is a read write overlay file system and also on the mtd0 because that one contains all
the other mtd blocks. The other checksums are OK. Cool, we have a backup of the original firmware
– now let’s go and flash. The process is very well documented on the OpenWrt website – all we
have to do is pull an image over the web using curl or scp or ftp it to the router and then
write it into the MTD block devices. Let’s go. This process takes a couple of minutes. But once
the router has rebooted then it will run OpenWrt and hence be available under the 192.168.1.1
address. As I have installed the snapshot image, I will have to install the web frontend manually.
I can do so by ssh’ing into the router, then I launch opkg update in order to update the software
package list from the OpenWrt repository and then I do an opkg install luci. Luci is the name of
the web frontend. If you use a release image, this will already be included and you can safely
skip that step. For the speed tests later we will need htop in order to monitor the CPU usage, so
let me also run opkg install htop to get that. Just checking that Luci, the OpenWrt web
interface, is available on the IP address 192.168.1.1. All working, all good. By the
way – if I want this to look a bit more modern then I go to system-then software and I search
for theme. The look and feel of luci can be adapted with themes, for example the OpenWrt2020
theme makes it look a bit more… you know modern. But now let’s go for the
performance tests. Same scenario like with the stock firmware or in the
previous video. First the Switch test, that means both endpoints are connected to
the LAN1 and LAN2 interfaces and I run iperf3 in order to measure the Ethernet throughput
without routing – in the same subnet. We can see that we get roughly the same performance
like with the stock firmware here and 0% CPU. Now the Routing test. No surprise, the
performance is not great as it uses the CPU. We can see the CPU usage here in htop. So let’s enable software offloading
in luci under network-firewall. Yes, this is much better. Last but not least I tick the hardware
offloading box – and – that gives roughly the same performance like with the
stock firmware – but keep in mind that Smart Queue Management SQM and Quality of
Service QoS will presumably be unusable as of now. One more test to go – the WiFi performance test. I
have two iperf3 server instances running on ports 5201 and 5202 on my proxmox Server and then I
connect via the Wifi with my laptop and later with the iphone, both will run iperf3 in client mode.
One on the 5201 port, the other on the 5202 port. Connecting the first client –
roughly the same Throughput like with Stock firmware but with higher CPU usage. Connecting the second client and the
throughput drops to 200 Mbit on one and roughly 100 Mbit on the second.
Quite similar to stock again. Awesome. Let’s sum up quickly. I have summarized the findings here in this
table. The performance of stock firmware and full OpenWrt are about the same
but with higher CPU usage on OpenWrt. With regards to the built in data collection
and cloud Management capabilities of the router I have decided that there is no way that I would
use the stock firmware but rather be in control and use OpenWrt. And again guys, I have decided
this for myself – I am not your dad – at least to the vast majority of you – so you are of
course totally free to decide for yourselves. Given the fact that the device only
has 2 LAN ports and a WAN port, so 3 Ethernet ports in total the use
case as a router and switch might be limited. But it definitely
makes a good access point. Comparing it to the D-Link DIR-2660 which I
tested in the last video it turns out that the device performs not so good, I’d say at 80
to 90% of the D-Links performance – but hey, it only costs a fraction of the D-Link’s
price. The D-Link sells for 100 to 150 Dollars while the Xiaomi can be bought for roughly 30
Dollars. So given the huge price difference I think it is definitely a go if the limitations
like the number of Ethernet ports, maximum of 867 Mbits on the 5 GHz band, the missing Wall mount
and the missing USB port are not a showstopper. I also checked if the WiFi hardware supports
mesh point mode – and it does – so a good use case could be to actually use the
device as a mesh point in a 5 GHz mesh. I might make a video on that shortly. So far for this episode guys – do not
forget to leave me a like and a comment and to subscribe so that you won’t
miss out on the next episodes. Until then - many thanks for watching,
stay safe, stay healthy, bye for now.
