Pure lazyness on my part, I keep meaning to update when i get a moment! I've honestly not known or hear of anyone else experiencing reboots like you say so i'd probably think it was more hardware than software. perhaps check the temps of the chips inside your router and the quality of voltage from your PSU
I have AdBlock installed, maybe this is the cullprit. Not used many lists, i have 43.000 adresses blocked.
I will monitor the device, and, if i get another reboot, i will return to the standard image with no AdBlock.
Today I have got an OOM.
I suspect that AdBlock is the culprit, I have posted already an kernel crash log on the AdBlock forum.
Mon Oct 12 07:16:16 2020 kern.warn kernel: [245805.233352] kthreadd invoked oom-killer: gfp_mask=0x15080c0(GFP_KERNEL_ACCOUNT|__GFP_ZERO), nodemask=(null), order=1, oom_score_adj=0
1 Like
Just a heads up for R4AC users (100m global) who are using their r4ac as a secondary router...
If you do not edit the information in: /etc/config/network internet from the r4ac will not work.
After some struggle with the two latest stable releases and now the most up-to-date snapshot release not having any internet - 'opkg update' producing 'Failed to establish connection
*** Failed to download the package list from *****- you need to manually specify gateway, dns and possibly change your LAN IP.
VI into /etc/config/network and then add the relevant lines under 'lan'. Should look something like this when done:
config interface 'lan'
option type 'bridge'
option ifname 'eth0.1'
option proto 'static'
option ip6assign '60'
option ipaddr '192.168.0.1' ##xiaomi router address
option gateway '192.168.1.1' ## master router address
option netmask '255.255.255.0'
option dns '192.168.1.1' ##master router address
Have fun!
ps.
Disabling ipv6 may also be useful for some isps to do that simply add:
config interface wan
option ipv6 0
2 Likes
Hey guys.
How can I build a firmware which is exactly the same config with stable release? Are these commands correct? Thanks in advance.
git clone https://git.openwrt.org/openwrt/openwrt.git
cd openwrt
git checkout v19.07.4
./scripts/feed update -a
./scripts/feed install -a
wget https://downloads.openwrt.org/releases/19.07.4/targets/ramips/mt7621/config.buildinfo -O .config
make defconfig
make
make defconfig will build for all possible targets. Unless you're a masochist, I doubt that's what you want 
You would want to make menuconfig and select only your device. But that's when you'll realize why we have our own builds for v19.07 (stable) branch: Mi Router 4A Gigabit is not supported, only in master version.
That's why, for example in my case, I have a fork of openwrt and in the 19.07 branch there are a few added things to backport support for it on this branch:
Well, you could then think "if I instead use that and make my build with exact same settings, I'll have everything including all kmods working". I wish that were true... because for each device, the signature always ends up being different. But if you find a way to work around that in a way they work... I'm all ears
That's why in my latest build I made a ZIP with a bunch of kmod packages for everyone to be able to install the necessary dependencies and then successfully install most (if not all?) stable packages.
But if you're into it, please clone that branch in my repo and improve it at will. The more improvements, the better for everyone 
- at least until openwrt 20.x stable comes out, which should already include our device in their builds.
Best regards.
2 Likes
Forgot to add: the latest build I did is not on a branch, but a tag. So after cloning you can do
git checkout v19.07.4-xiaomi-miwifi-3gv2-mt76updated-2020-09-18-fix_mtk_eth_timeout
and if you also want to make a build exactly the same as I published, the config file is on the releases page for that tag. Happy fiddling around with openwrt!
1 Like
Tried a few different versions of the 100M R4AC global build (both latest stables and snapshot) and I can't seem to figure out the nomenclature used with reference to what is regarded as 'stable' or otherwise 
. Can somebody explain to me briefly when somebody ports openwrt to the latest hardware what kind of testing goes in to determine whether a build is 'stable' or developer-only?
your build is stable enough for my router. (bought mi4a gigabit late 2019)
I wonder newer hardware have slightly different chips config that make "unstable" for them.
Usually stable means it is a released version, or based on a released version, announced by openwrt team. Latest stable is 19.07.4. When they launch a new stable series (e.g. 19.x) they create a branch and next 19.x releases will tipically have only critical fixes, not support for new (or very different) hardware. That of course will vary, but it's the case of Mi 4A Gigabit which isn't available on official 19.x stable releases (hence the ports and build by some users here in the forum).
Snapshots on the other hand are built every night on the latest code, which is changed daily. Besides being more unstable for that, also has the disadvantage that you'll most likely have trouble installing packages later because those are overwritten every night, so if you want to try a snapshot build and install packages, you should do that on the same day. Your mileage will vary according to the day you install from that branch... before flashing a new snapshot (when you have already flashed one a few days ago), I recommend to take a look at latest commits on the openwrt git and see if there is something new that makes it worth - after all, don't forget the flash on these devices isn't infinite (although supposedly you should be able to overwrite its contents hundreds to thousands of times).
Of course you can be unlucky and a stable version build gives problems with your specific hardware, whereas a snapshot build works fine, and hence that snapshot will be more "stable" (in the specific sense of the word). But it's life in computer world
Hope that clarifies.
2 Likes
So I thought i chime in on this thread, I currently recieved this device and attempting to fix an outstanding issue with oversized kernel images - greater than 1.5mb, causes squashfs corruption errors! when booting. Using the initramfs image works as its below 1.5mb in size.
Also there is a way to enable the u-boot tftp method and uart control access without using an spi programmer.
When doing the exploit, there is a command called 'nvram', all you need to do is the following:
- nvram show - gives you the output of current set options stored
- To enable uart keyboard actions - 'nvram set uart_en=1'
- To make uboot delay boot work - 'nvram set boot_wait=on'
- Set boot delay to 5 - 'nvram set bootdelay=5'
once this is done you need to set the config to the spi eeprom
'nvram commit'
Then using the uart lead you can now interact with the uboot on bootup.
Will update on the corruption fix.
4 Likes
I cant seem to find the post but i think thats common to the hardware, I think there is a size limitation. Someone else might rember but i think it was due to the compression method and there may be a fix but not in this version (don't quote me!). Thanks for the great info with nvram, I'm sure a lot of people will find this info handy!
1 Like
No problem.
So i've done the lzma loader patch (patch comments in the openwrt git repo), but still no joy. So it seems there is a limit higher than 1.5mb. Stripping the kernel image down to 1.6mb, it would boot fine for the v19.04.4 codebase. There are a hacky workarounds for other devices having the same issue. It all boils down to the Xiamio using old versions of U-boot 1.1.3 and weird limits etc.
Will post my fixes later..
1 Like
Hey. I once tried to backport the lzma loader too but based on the feedback I got at that time, it wasn't solving any of the similar issues some people were having.
Still, it also didn't cause problems for others.
If you're interested, you may take a look here:
Maybe cherry-picking some of those commits (after the last) can help?
2 Likes
Yep thanks, i saw on this thread people where still having issues. Myself had the same issues.
I'm tempted to make my own u-boot loader and get rid of this stupid issue altogether.
1 Like
So am I correct in assuming that nothing really gets tested independently as such, merely ported to a new chipset or updated to include new component support?
If this is the case what if there are problems accommodating new components or SoCs, how does the core software morph to accommodate the needs of particular hardware environments?
What people need to understand is that these devices are just manufactured on the cheap, sell as many as possible - them move on, rinse and repeat. Its been the business model of china for decades.
What makes matters worse is that these manufactures don't care about supplying code or how it works, if it barely works, great!
Take example of this device, OEM - kernel 3.10 and u-boot 1.1.3 - this is a typical kernel amongst Android devices, so the chinese devs just reuse the same process, slap in a few patches and boom it works.
Now the brick walls are coming, creating cryptic parameters so people can't talk to the device without going through loops to get past it.
Project like this (openrwrt), and volunteers like us, bring it upon us to get it to work for everyones benefit - including my own (cheap hardware), plus i love a challenge!.
So you are correct nothing gets tested properly, just base work on similiar devices and add patches to make it to work - and get around new brick walls
2 Likes
That I can't tell you. Maybe openwrt maintainers will answer but most likely not on this thread. Perhaps open a new one, not tied to this device only, and someone will answer, I guess...
Thanks very much for chiming in, but to clarify, I understand from a manufacturers POV how they might approach the product cycle with planned obsolescence and such, but from the perspective of this community effort, how do we go about having our own standards or maintaining a certain quality consistency across builds? This is what I thought terms like 'dev/snapshot' and 'stable' were supposed to signify in so far as reliability is concerned. Like how you have Debian, with a maximum stability approach but a super slow release cycle, and then you know, the more risque Ubuntu with a more flexible approach, and of course Redhat with enterprise level support and such.
Thank you so much for your reply. Have a nice day!