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!
With some devices, your analogy works some of the best-supported devices have been around a long time and have grown in maturity as you would expect. However, as far as I can tell the 4A released 12-03-19, this thread started 2 months later and a reliable exploit took a bit more time to develop. So in the example of Debian life cycles of 2years were a long way off (as per your analogy), I wouldn't expect and still don't expect Debian to run out the box with every Motherboard and Graphics card because it dosen't even still.
It's probably better to look at OpenWrt for what it is, it's a custom firmware, it's damn stable for something that was created from reverse-engineering the device, yes you might come across some issues but thats what this forum is about, outlining those issues and hopefully us all working together to iron out anything as best we can.
Another angle to look at is that it is stable, for the chip (Not router) if it is designed under perfect conditions. How the OEM builds the device and what hacky work arounds they use to get it to run or improve performance itsn't nessasarily taken into account.
5 Likes
What commit specifically is supposed to fix the transmit queue has timed out issues?
The one on top of the tag:
Or if you want to see it in the openwrt 19.04 branch:
This one arrived right after 19.07.4 was released. But without this I had severe and constant issues on another ramips device (although not the Mi) so I cherry-picked it in my latest build. If you see the order of the commits in my latest build tag, you'll see I've changed the order so that it's applied before the ones that set the opkg repositories to the release. Cheating on my part? Perhaps 
But I didn't have that issue again.
1 Like
@araujorm @hoddy I've started a new thread on a fix of mine, as this thread is getting too long
If you could have a go and let me know any feedback and testing.
1 Like
Excellent response Hoddy. I didn't mean to be presumptuous, in fact, I've enjoyed using OpenWrt/tomato/dd-wrt for years across a number of devices and have never fully understood how exactly they organise it. Your final point about chipset support in isolation (without the proprietary kludges and hacks) I think explains the situation best. Having said all that, should I just post my results here, problems and such? Is that the accepted protocol? Would be great to contribute in some more meaningful way.
1 Like
Thanks, it's a good question. It's not a perfect art but we try, very thankful for those creating the builds as best as they can for us all to use! I think we are all hoping for a bit more support in the next version of OpenWrt.
Yeah, post your 4A problems here or if your using @db260179 's version in his new thread above and i'm sure we will all try to help as best we can. Really thats the "accepted" but just make sure its relivent too the 4A here. Hopefully someone will be able to help!
1 Like
Hi,
I can't find the solution to reset my router.
I've got a R4A (Gigabit version), and I tried to update manually the firmware with the global (english) version 3.0.24. The update never ended because the router led was still orange after 30minutes so I unplug it a replug it.
Now I don't have ane IP anymore when I connect the router, and always have an orange LED.
I tried to put IPv4 to 192.168.31.2 ans 192.168.1.2 but with TinyPXE, it never works.
I just want to go back to the original version... May you help me please ?
Thank you very much
Cheers
Tiny PXE :
12:56:17 DHCPc:discovering for another DHCPd on LAN
12:56:17 ROOT=C:\Users\xxx\Downloads\TinyPXE
12:56:17 DHCPd 192.168.31.4:67 started...
12:56:17 TFPTd 192.168.31.4:69 started...
12:56:22 DHCPc:no other DHCPd discovered
So the debrick method will only ever work on the 192.168.1.x range so don't use .31, .31 will only work once the new firmware has been uploaded (and at that point you can just use DHCP if you want). Make sure you have connected directly between the router and PC (nothing else on network) and you're using one of the LAN ports (not the WAN port). Also, make sure you are holding the reset button when powering on the router.
Just register an account)
@araujorm
I had the same issue reoccur so have now disabled packet_steering, based on reading the following:
It was a performance tweak I had applied manually that was variance from your vanilla build.
I plan to take a look at @db260179 firmware at some point, but first need to isolate if another issue was related to this. Currently I have 1 device running your build, and the other is running a snapshot build (OpenWrt SNAPSHOT r14553-7dc78d1d28 / LuCI Master git-20.267.56601-1da9df8).
The global firmware will fail going from a CN firmware due to verifcation error on attempt of upgrade via the oem web page.
I will attempt a new u-boot bootloader in the future for this device, on my to do list
1 Like
Hey just thought you might want to know, it appears your most recent zip has a stale kmod-tun kernel module built for some previous kernel/build. When I try to install it, it complains about the kernel version, when I force it, the module won't load. And, indeed, your latest config doesn't have kmod-tun enabled, so I assume it's an old package from a previous build that accidentally made its way into the zip.
The image works great otherwise, thank you! I've been trying to build my own from the master branch of the OpenWrt repository, but I have a weird problem with the WAN interface, it just keeps resetting:
Sun Oct 18 13:47:47 2020 daemon.notice netifd: Network device 'wan' link is up
Sun Oct 18 13:47:47 2020 daemon.notice netifd: Interface 'wan' has link connectivity
Sun Oct 18 13:47:47 2020 daemon.notice netifd: Interface 'wan' is setting up now
Sun Oct 18 13:47:47 2020 daemon.notice netifd: Interface 'wan6' has link connectivity
Sun Oct 18 13:47:47 2020 daemon.notice netifd: Interface 'wan6' is setting up now
Sun Oct 18 13:47:47 2020 kern.info kernel: [ 75.105466] mt7530 mdio-bus:1f wan: Link is Up - 100Mbps/Full - flow control rx/tx
Sun Oct 18 13:47:47 2020 daemon.notice netifd: wan (2733): udhcpc: started, v1.31.1
Sun Oct 18 13:47:47 2020 daemon.notice netifd: wan (2733): udhcpc: sending discover
Sun Oct 18 13:47:48 2020 daemon.notice netifd: Network device 'wan' link is down
Sun Oct 18 13:47:48 2020 daemon.notice netifd: Interface 'wan' has link connectivity loss
Sun Oct 18 13:47:48 2020 daemon.notice netifd: Interface 'wan6' has link connectivity loss
Sun Oct 18 13:47:48 2020 kern.info kernel: [ 76.129401] mt7530 mdio-bus:1f wan: Link is Down
Sun Oct 18 13:47:48 2020 daemon.notice netifd: wan (2733): udhcpc: received SIGTERM
Sun Oct 18 13:47:48 2020 daemon.notice netifd: wan (2733): udhcpc: entering released state
Sun Oct 18 13:47:48 2020 daemon.notice netifd: wan (2733): Command failed: Permission denied
Sun Oct 18 13:47:49 2020 daemon.notice netifd: Interface 'wan' is now down
Sun Oct 18 13:47:49 2020 daemon.notice netifd: Interface 'wan6' is now down
### And then it repeats, over and over again
Sun Oct 18 13:48:00 2020 daemon.notice netifd: Network device 'wan' link is up
Sun Oct 18 13:48:00 2020 daemon.notice netifd: Interface 'wan' has link connectivity
### and so on...
Anyone else experiencing this problem? @araujorm's build works fine, so I'm trying to reconfigure that per my own needs, so far I haven't been able to get it to compile, but it's a work in progress. Still, even if I get the stable build working, I'm really interested in what could be happening here.
Hi.
Been checking... something looks fishy indeed with that module. Will try to rebuild properly later.
As for the instability of the master version, that's a problem inherent to it... if you try tomorrow maybe they've fixed it... or try to see the latest commits and rollback to before a suspicious one. That's why I prefer using something based on the stable version, sometimes performance may not be the best of the best, but there are less surprises.
1 Like
I wouldnt use the master snapshot, its always a moving target.
Try my new commit - https://gitlab.com/db260179/xiaomi-m4a/-/commit/4dd052bebdcaf48bd89e2ed2f54a13ead96e4fc5
I've noticed interfaces going up and down and traffic issues. Let me know if you have a good result no a build from my repo.
I have a quick build.sh script to make life easier.
Also the way openwrt builds kernel modules and links to the current kernel, then symbols from the openwrt master build repo will not work - reason for forcing the module insert.
@araujorm Best supply a imagebuilder so people can add kernel modules and create a custom image.
1 Like
Nice, thank you @araujorm and @db260179, all you say makes sense. And yeah master really isn't the optimal choice, but I didn't know what else to use before digging through this thread and finding these stable builds. I'll give it a shot @db260179, thanks!
Made a new build.
Using an online repo now, most annoyances with kmod packages should be fixed I hope. No need to copy anything manually any more. If you were using the previous release that was made available in a big zip file, please update to this one.
Other than that, it includes a tweak suggested by @db260179 to define the image block size. May help to install it on some devices that had squashfs errors before (please provide feedback).
As an alternative, I strongly suggest to look at the thread @db260179 opened to share his work, check his work and provide him the most useful feedback, as some of his discoveries are looking very promising IMO.
4 Likes
Damn, now I'm not sure which repo to use... Wonderful, thank you!