I was just wondering whether a newer GPL wouldn't perhaps fix some of the issues reported lately for the AC models (i.e. when using 386.9 - 386.11 based on GPL 50757 and 386.12 based on GPL 51997).
Release Asuswrt-Merlin 386.12_6 is now available for AC models
- Thread starter RMerlin
- Start date
- Status
sad-spirit
New Around Here
It probably does: I looked at the sources of Tor and it should log errors if it actually failed reading from /dev/urandom
Debugging Tor is not something I'm able to easily do, unfortunately...
Any changes in build environment?
Tech9
Part of the Furniture
Thank you. I remember reporting to Asus broken things around QoS with IPv6 enabled, but it was with the previous firmware release. I believe the bugs are still present after Trend Micro quick fix release. Will bring home one RT-AC68U next week and run the tests again. I know it's in closed source part and Asus has to look at it, eventually.
Make sure it waits for enough entropy to be generated before starting it.
None.
Diamond67
Senior Member
Somehow amtm and Diversion major upgrades (December 2023), which e.g. disabled uiDivStats and removed pixelserv-tls, fixed my serious radio problems which I faced with earlier Merlin firmware versions 386.12_2/4. Of course I have no real proof of this. But my wifi has been up and running very reliably since the amtm and Diversion upgrades.
Haven't got any wifi issues after updating to fw 386.12_6 either. Uptime 3 days 12 hours.
Indeed, and thanks! I was using a Diversion feature incompatible with the new dnsmasq 2.90.
Upgraded Diversion to v5.1.1, and then upgraded AC86U to 12_6. Everything appears to be working now (knock on wood).
15:25:58 kernel: Pid: 1700, comm: wred
Mar 4 15:25:58 kernel: CPU: 0 Tainted: P (2.6.36.4brcmarm #1)
Mar 4 15:25:58 kernel: PC is at 0x40085a8c
Mar 4 15:25:58 kernel: LR is at 0x401547ac
Mar 4 15:25:58 kernel: pc : [<40085a8c>] lr : [<401547ac>] psr: 80000010
Mar 4 15:25:58 kernel: sp : bd5ffdf0 ip : 4015df60 fp : bd5ffe6c
Mar 4 15:25:58 kernel: r10: 40162020 r9 : 401623dc r8 : 00000000
Mar 4 15:25:58 kernel: r7 : 000000b3 r6 : bd5ffea0 r5 : bd5ffe00 r4 : 4015dd74
Mar 4 15:25:58 kernel: r3 : 00000000 r2 : 80000000 r1 : 00000008 r0 : fffffdfe
Mar 4 15:25:58 kernel: Flags: Nzcv IRQs on FIQs on Mode USER_32 ISA ARM Segment user
Mar 4 15:25:58 kernel: Control: 10c53c7d Table: 9cf8804a DAC: 00000015
A few of the above in the log today. What is wred?
Mar 4 15:25:58 kernel: CPU: 0 Tainted: P (2.6.36.4brcmarm #1)
Mar 4 15:25:58 kernel: PC is at 0x40085a8c
Mar 4 15:25:58 kernel: LR is at 0x401547ac
Mar 4 15:25:58 kernel: pc : [<40085a8c>] lr : [<401547ac>] psr: 80000010
Mar 4 15:25:58 kernel: sp : bd5ffdf0 ip : 4015df60 fp : bd5ffe6c
Mar 4 15:25:58 kernel: r10: 40162020 r9 : 401623dc r8 : 00000000
Mar 4 15:25:58 kernel: r7 : 000000b3 r6 : bd5ffea0 r5 : bd5ffe00 r4 : 4015dd74
Mar 4 15:25:58 kernel: r3 : 00000000 r2 : 80000000 r1 : 00000008 r0 : fffffdfe
Mar 4 15:25:58 kernel: Flags: Nzcv IRQs on FIQs on Mode USER_32 ISA ARM Segment user
Mar 4 15:25:58 kernel: Control: 10c53c7d Table: 9cf8804a DAC: 00000015
A few of the above in the log today. What is wred?
scjr
Very Senior Member
Upgraded from 12_4. No prior issues. 5 days uptime on 12_6, with no issues.
I don’t consider thanking the person who works hard on this project as “nonsense”, but I appreciate your feedback.
Ripshod
Part of the Furniture
It's linked with QoS I believe (Weighted Random Early Detection).
ColinTaylor
Part of the Furniture
The saga continues. After 6 days of stable operation, my AC86U crashed again.
BUT this time I actually managed to connect by wire and extract some interesting logs!
Context:
When I connected via ethernet in my wired Aimesh node and accessed the Asus Web-interface, I could see that:
Background:
I had connection drops with .12 and downgraded to .11. After over a week of seemingly stable operation with .11, it crashed just like in this case (but I couldn't get the logs), and now .10 crashed with this log.
Possible cause?:
The only remotely possible cause I can think of is that I remember a long time ago connecting through Putty and entering some code in order to save the logs between reboots in the routers internal partition. But I have set "Enable JFFS custom scripts and configs" to "No", so that would disable such a script anyways? Besides, I don't see a steady buildup of RAM usage until crash. So I doubt this has anything to do with the issue.
Factory reset is unfortunately hard to do in this environment, so it is not something I can easily attempt, partly because of a know issue with AC66U_B1 routers that refuse to pair with Aimesh, so I cannot afford the risk of erasing its current pairing with the AC86U main.
Log (had to split it in two messages because of limit):
BUT this time I actually managed to connect by wire and extract some interesting logs!
Context:
When I connected via ethernet in my wired Aimesh node and accessed the Asus Web-interface, I could see that:
- all the wireless clients on all 3 Aimesh nodes (1 wired, 2 wireless) had no clients connected (this happened as a result of the crash).
- Only the AC86U (main) had wireless clients connected
Background:
I had connection drops with .12 and downgraded to .11. After over a week of seemingly stable operation with .11, it crashed just like in this case (but I couldn't get the logs), and now .10 crashed with this log.
Possible cause?:
The only remotely possible cause I can think of is that I remember a long time ago connecting through Putty and entering some code in order to save the logs between reboots in the routers internal partition. But I have set "Enable JFFS custom scripts and configs" to "No", so that would disable such a script anyways? Besides, I don't see a steady buildup of RAM usage until crash. So I doubt this has anything to do with the issue.
Factory reset is unfortunately hard to do in this environment, so it is not something I can easily attempt, partly because of a know issue with AC66U_B1 routers that refuse to pair with Aimesh, so I cannot afford the risk of erasing its current pairing with the AC86U main.
Log (had to split it in two messages because of limit):
Hotplug isn`t necessarily the source of the leak. It just happens to be the process that tried to run, and there wasn't enough free memory for it to launch, causing it to crash.
I would first check that /tmp isn't getting filled by something, eating up all available memory.
I will keep taps on it in the coming days.
I guess nothing seems out of the ordinary right off the bat...?. How much do you expect /tmp/ to fill up before it looks like something is fishy?
Last edited:
If it starts growing to multiple dozens of megabytes, I would start looking at what is using all that space in it.
@RMerlin
I have over 3 days of uptime now, and the size of the tmp folder has hovered stably between 2.6-2.9mb. Memory use overall according to the WebGUI is 435mb/512mb with CakeQOS and 19 clients on 3 aimesh nodes (1 wired, 2 wireless), low amounts of traffic.
Seeing as the crash seems to come after about 1-2 weeks, I think I should have seen some accumulation in the /tmp/ folder by now if that's where the culprit lies?
So do you have any other suggestions on possible culprits that i can check/keep tabs on?
Btw. regarding the logs i posted earlier: Any ideas on why the result of the memory leak is that the router runs for about 8 more minutes before it restarts, and after that renders all the Aimesh nodes useless/unable to connect clients (wired and wireless) and only the main AC86 router working? In other words, it is not a complete restart but a partial one that renders only the main router working again, not the Aimesh nodes, because when I manage to connect via ethernet and do a proper restart via the WebGUI, the whole network including the Aimesh setup is back to working. Is this something that can be improved in the code on your side, ie. that it does a proper restart when a memory leak crash happens, and not a partial one?
(For the record: I haven't even checked that the AC86 worked properly after the crash because it's placed a long distance from my computer. What happened was that it rolled over from the broken Aimesh connection to the AC86U at about 150mbps on the 2.4ghz network, and it only worked for very short bursts, minutes in-between. Spent 15 minutes trying to access the web interface on that weak connection before I gave up and connected by wire via the Aimesh node in order to access SSH and reboot. Which suggests to me that something is not working properly because 150mbps connection (according to MacOS) is supposed to provide me a stable enough connection, an almost completely unresponsive one. Anyways, dunno if that's relevant but I like to include everything just in case.)
I have over 3 days of uptime now, and the size of the tmp folder has hovered stably between 2.6-2.9mb. Memory use overall according to the WebGUI is 435mb/512mb with CakeQOS and 19 clients on 3 aimesh nodes (1 wired, 2 wireless), low amounts of traffic.
Seeing as the crash seems to come after about 1-2 weeks, I think I should have seen some accumulation in the /tmp/ folder by now if that's where the culprit lies?
So do you have any other suggestions on possible culprits that i can check/keep tabs on?
Btw. regarding the logs i posted earlier: Any ideas on why the result of the memory leak is that the router runs for about 8 more minutes before it restarts, and after that renders all the Aimesh nodes useless/unable to connect clients (wired and wireless) and only the main AC86 router working? In other words, it is not a complete restart but a partial one that renders only the main router working again, not the Aimesh nodes, because when I manage to connect via ethernet and do a proper restart via the WebGUI, the whole network including the Aimesh setup is back to working. Is this something that can be improved in the code on your side, ie. that it does a proper restart when a memory leak crash happens, and not a partial one?
(For the record: I haven't even checked that the AC86 worked properly after the crash because it's placed a long distance from my computer. What happened was that it rolled over from the broken Aimesh connection to the AC86U at about 150mbps on the 2.4ghz network, and it only worked for very short bursts, minutes in-between. Spent 15 minutes trying to access the web interface on that weak connection before I gave up and connected by wire via the Aimesh node in order to access SSH and reboot. Which suggests to me that something is not working properly because 150mbps connection (according to MacOS) is supposed to provide me a stable enough connection, an almost completely unresponsive one. Anyways, dunno if that's relevant but I like to include everything just in case.)
- Status
Similar threads
Similar threads
Similar threads
-
AC-86u vulnerability tracking post-EoL (asuswrt-merlin 386.14_2)
- Started by JTnola
- Replies: 8
-
-
-
Asuswrt-Merlin 3004.288.8_4 /jffs Partition Nuked on Random Reboot- Started by garycnew
- Replies: 6
-
-
-
-
-
-
Asuswrt-Merlin v3006.102.5 channel/bandwidth switching
- Started by BeachGuy
- Replies: 4