Only the config-min build - it has the luci-ssl and luci-sqm and network tools.
since yesterday with sqm (cake-piece of cake) enabled is stable so far no issues... nice work
3 Likes
Well done my friend. It works fine on my device. Thank you for your hard work.
But can you fix the model name proper as "Xiaomi Mi Router 4A Gigabit Edition" please?
source: https://github.com/openwrt/openwrt/blob/master/target/linux/ramips/dts/mt7621_xiaomi_mi-router-4a-gigabit.dts
Additionally, are you going to implement these fixes on the official openwrt github repo as well as yours?
ulpian
I wondered if anyone else was going to notice this 
@db260179 The model name letter casing does not quite align to the official product.
I hope your fixes reach the official OpenWrt Github, @db260179.
It would be amazing for all of us users.
Is this what you mean?
At the moment there are alot of changes that will affect other mt7621 devices.
I will do some cherry picking later and send a pull request to fix the current openwrt v19.07 for this device and the 3GV2
Will need more time from users to confirm that the current issues are resolved.
Yes I think so. Thank you so much for fixing. Cheers.
ulpian
Here is a built image with new change and imagebuilder and packages
https://openwrt.org/docs/guide-user/additional-software/imagebuilder - to use the imagebuilder guide
Just change the repositories.conf and add the extra packages to link correctly the linked kernel packages that are not in the official branch
src base file:///packages/mipsel_24kc/base
src luci file:///packages/mipsel_24kc/luci
etc etc
Enjoy!
1 Like
Just updated to this build, after a few hours everything seems working well and pretty snappy! I am using a 3A power adapter just in case. I will let you know how it goes in the next days!
2 Likes
The CTRL-EVENT-BEACON-LOSS spam in the log that I had before has disappeared!
With this release the connection is pretty stable, however I still had a firmware restart:
Mon Nov 30 15:22:52 2020 kern.err kernel: [74617.664540] mt76x2e 0000:01:00.0: MCU message 31 (seq 8) timed out
Mon Nov 30 15:22:52 2020 kern.info kernel: [74617.725662] mt76x2e 0000:01:00.0: Firmware Version: 0.0.00
Mon Nov 30 15:22:52 2020 kern.info kernel: [74617.731310] mt76x2e 0000:01:00.0: Build: 1
Mon Nov 30 15:22:52 2020 kern.info kernel: [74617.735493] mt76x2e 0000:01:00.0: Build Time: 201507311614____
Mon Nov 30 15:22:52 2020 kern.info kernel: [74617.764513] mt76x2e 0000:01:00.0: Firmware running!
Mon Nov 30 15:22:52 2020 kern.info kernel: [74617.774738] ieee80211 phy1: Hardware restart was requested
It only happened once in the day, while I was in a Skype group call, and it recovered on its own shortly after.
Under certain load conditions this is normal.
You could try and experment with the HW offloading or SW offloading feature in the firewall section.
This part of the log indicates the mcu unit had timed out, so signalled a hardware reset - the watchdog gets triggered in this situation then
happens to resolve itself.
Does hardware offloading serve to improve stability?
Its and big IF, but it should help soften the network load from the cpu cores. Basically the cpu's are doing all of the work, so if they get tied up, then errors like this occur.
By letting the switch offload traffic parse through with minimal cpu usage, then hopefully it doesnt timeout so much.
Give it a try, best monitor the load, have a load program monitor its cpu usage, that way you can capture if the cpu is getting maxed out
In a shell look at the '/proc/interrupts' see what the cpu and errors.
But remember SQM/QOS doesnt work correctly when softoffload or HW offload is enabled!
1 Like
How long do you consider that the router should behave in a stable way to consider your patches as effective?
Hi @db260179
I'm currently running OpenWrt 19.07.4 r11208-ce6496d796 / LuCI openwrt-19.07 branch git-20.247.75781-0d0ab01
in my Xiaomi Mi Router 4a gigabit
I just saw this thread and the post of your new compilation,
I have downloaded it, my question is which one should I flash
...kernel.bin or sysupgrade.bin. I am a newbie in this aspect
I would appreciate your help, I would like to be able to use adblock or banIP and if possible SQM scripts I am from Mexico I apologize for my English.
Hi, no need to apologize if english is not your first language.
So the -initramfs-kernel image is mostly used for testing without flashing.
You would always use the -sysupgrade image.
So i've added the imagebuilder, so that you can build your own image without recompliling everything.
If you follow that openwrt link you can build your own image
Just add those packages to a local folder so it can pickup the packages it wants.
@db260179 Thanks for your compilation, first of all, it helped me a lot for the SQM scripts, I installed BanIP without problems, I only need to install BBR congestion control but it is not supported by the kernel, I will try to cook my own image.
[image]
1 Like
@db260179 Thanks, now running custom config of your v1.3 release. No issues so far. 5G speed seems like it may have improved slightly but cannot confirm for sure due to a number of other factors.
Do you happen to know where the initial date/time in syslog comes from prior to NTP setting the time?
1 Like
Like all embedded devices without a rtc, date and time will be taken from either a preset manufactuer date.time or default 01-01-1970
Thing is, my observation is that this date seems to increase with firmware releases and is not the default 1970 start date.
It does not seem to directly relate to the actual firmware compile date, but maybe something to do with one of the repo commit dates or files?
For example, I compiled your last release (using totally fresh git clone), just after midnight on Friday 04 Dec. but the startup date shown in syslog for the applied firmware is Fri Nov 27 15:26:00 2020 prior to NTP kicking in.
The previous build I was running booted with Tue Nov 24 13:19:28 2020 kern.notice kernel: [ 0.000000] Linux version 4.14.206 (builder@buildhost) (gcc version 7.5.0 (OpenWrt GCC 7.5.0 r11208-ce6496d796)) #0 SMP Sun Sep 6 16:19:39 2020 therefore this must be controlled by OpenWrt compile somewhere.
Just an observation I thought worth sharing if useful to anyone
I'm pretty sure the date at the end of the line relates to the kernel date (but my linux is slightly rusty).