Release Asuswrt-Merlin 386.12 is now available for AC models

[L&LD]

Your daily reboots are either masking any underlying problems with your setup/config or, are creating them.

What is the point of having the router automatically reboot?

 

[Micharlie]

Your daily reboots are either masking any underlying problems with your setup/config or, are creating them.

What is the point of having the router automatically reboot?

I disabled reboot this morning. Let’s see what happens. I always had daily reboots and never had an issue. What’s the bad thing about havind daily reboots? Just curious.

 

[KrypteX]

I disabled reboot this morning. Let’s see what happens. I always had daily reboots and never had an issue. What’s the bad thing about havind daily reboots? Just curious.

Nothing wrong IMHO. I automatically turn off WiFi during the night - I sleep better. No tinfoil hat, though.

 

[L&LD]

Daily reboots for no reason put more wear and tear on the routers' components.

Can hide underlying issues.

Isn't needed in any well-functioning network.


Btw, turning off your WiFi is of negligible benefit if you have neighbors around. Even if you're on a deserted island, the lifespan of humans is less than the detrimental effects of radio waves that we've been subject to since the dawn of time.

 

[KrypteX]

Even if you're on a deserted island, the lifespan of humans is less than the detrimental effects of radio waves that we've been subject to since the dawn of time.

I'd really have a ton to say to refute that statement, but won't. Give this a try: https://www.amazon.com/dp/1645020096/?tag=snbforums-20

 

[bibikalka]

Daily reboots for no reason put more wear and tear on the routers' components.

That's kind of hard to believe. There are no moving pieces inside. What's the exact mechanism for added wear and tear from more frequent reboots?

 

[L&LD]

@KrypteX, you can't refute that statement. It is true.

That book isn't really as authoritative as it is speculative. Many such books are used to boost random people's bank accounts. Doesn't make any one (let alone most/all) of their claims true.

It's laughable what it states about the declining bee population. Like there were stats before.

I can tune into social media, and ask ChatGPT to write me a few chapters (a paragraph at a time), and I could have such a book too. Won't make the claims any more true. No matter how unique of a perspective I provide and how able I am to make stats lie to support any conclusion I wish it to.

No, not hard to believe, @bibikalka.

Electrons move. Flash/NVRAM wears out. Sit happens. Voltage/amps surging to boot up a system can cause harm over time. Particularly vs a router in a steady state.

 

[heysoundude]

No, not hard to believe, @bibikalka.

Electrons move. Flash/NVRAM wears out. Sit happens. Voltage/amps surging to boot up a system can cause harm over time. Particularly vs a router in a steady state.

My undertstanding is that it's the heat/cool cycles stressing solder points & circuit boards, leading to eventual degradation and ultimately failure.

 

[bibikalka]

My undertstanding is that it's the heat/cool cycles stressing solder points & circuit boards, leading to eventual degradation and ultimately failure.

A reboot barely influences the temperature though - not enough time for that.

I do think that running at elevated temperatures makes the electronics age faster - but rebooting does not seem to contribute much.

 

[KrypteX]

@KrypteX, you can't refute that statement. It is true.

That book isn't really as authoritative as it is speculative. Many such books are used to boost random people's bank accounts. Doesn't make any one (let alone most/all) of their claims true.

It's laughable what it states about the declining bee population. Like there were stats before.

I can tune into social media, and ask ChatGPT to write me a few chapters (a paragraph at a time), and I could have such a book too. Won't make the claims any more true. No matter how unique of a perspective I provide and how able I am to make stats lie to support any conclusion I wish it to.

No, not hard to believe, @bibikalka.

Electrons move. Flash/NVRAM wears out. Sit happens. Voltage/amps surging to boot up a system can cause harm over time. Particularly vs a router in a steady state.

Electrons move! Huh, had no idea

 

[nonno]

I can confirm the issue on rt-ac68u wifi: I woke up this morning and could not connect to the wifi. No reboots, router running rock solid for several years with great uptimes. Trend micro ai protect enabled. Now back from work, router rebooted and wifi working again, let's see for how long.

 

[gmy]

Hi there, new in the forum with a possible related bug (or not).
I am aware of the problems that enabling AiProtection appears to cause in my AC86u router, but when enabled I constantly get this type of errors in the log (I searched for it but couldn't find anything related):

Nov 20 03:13:14 kernel: ct_p ffffffc01427a1c8 evict flow ffffff8000b59600 key 0x60002d86 before set key 0x60002e54 for flow ffffff8000b66400 cur_time 7610
Nov 20 03:13:14 kernel: ct_p ffffffc01674aa60 evict flow ffffff8000b7de00 key 0x60002fce before set key 0x60002df3 for flow ffffff8000b60300 cur_time 7610
Nov 20 03:13:15 kernel: ct_p ffffffc0111d3538 evict flow ffffff8000b49a00 key 0x60002c8a before set key 0x60002f90 for flow ffffff8000b7a000 cur_time 7610

Is this somehow related to TrendMicro, is it another bug or it's innocuous and I'm worrying about nothing? When I disable AiProtection it goes away.

ASUS RT-AC86U with Asuswrt-Merlin 386.12_2 and Skynet installed and running.
Thanks.

Does anyone have any idea of why my logs are flooded (first 1 every 5 seconds, now 5 per second) by this? I have one every 5 seconds since I updated to 386.12.2. Disabling AiProtection makes the log clean again. Only happens on my ac86u, my ac88u is fine...

Nov 21 22:31:58 kernel: ct_p ffffffc012464538 evict flow ffffff80009f4e00 key 0x2000173e before set key 0x200018ff for flow ffffff8000a10f00 cur_time 1130
Nov 21 22:32:00 kernel: ct_p ffffffc0166dd1c8 evict flow ffffff80009fe300 key 0x200017d3 before set key 0x2000192a for flow ffffff8000a13a00 cur_time 1130
Nov 21 22:32:00 kernel: ct_p ffffffc016a28dd0 evict flow ffffff80009f6a00 key 0x2000175a before set key 0x20001930 for flow ffffff8000a14000 cur_time 1130
Nov 21 22:32:05 kernel: ct_p ffffffc01231ca60 evict flow ffffff80009feb00 key 0x200017db before set key 0x20001990 for flow ffffff8000a1a000 cur_time 1140
Nov 21 22:32:20 kernel: ct_p ffffffc0145ce380 evict flow ffffff80009fed00 key 0x200017dd before set key 0x20001a82 for flow ffffff8000a29200 cur_time 1150
Nov 21 22:32:28 rc_service: httpd 5577:notify_rc restart_wrs;restart_qos;restart_firewall
Nov 21 22:32:56 wlceventd: wlceventd_proc_event(530): eth6: Auth [censored], status: Successful (0), rssi:0
Nov 21 22:32:56 wlceventd: wlceventd_proc_event(559): eth6: Assoc [censored], status: Successful (0), rssi:0
Nov 21 22:32:57 dnsmasq-dhcp[6319]: DHCPDISCOVER(br0) [censored]
Nov 21 22:32:57 dnsmasq-dhcp[6319]: DHCPOFFER(br0) [censored]
Nov 21 22:32:57 dnsmasq-dhcp[6319]: DHCPREQUEST(br0) [censored]
Nov 21 22:32:57 dnsmasq-dhcp[6319]: DHCPACK(br0) [censored]

 

[RMerlin]

Asuswrt-Merlin 386.12_4 has been released. This updates OpenVPN to 2.6.8 to resolve a crashing issue introduced with 2.6.7.

 

[Maverickcdn]

Asuswrt-Merlin 386.12_4 has been released. This updates OpenVPN to 2.6.8 to resolve a crashing issue introduced with 2.6.7.

Looking promising... the fatal error message has returned like in <2.6.7 , thank you fine sir

Nov 21 22:03:33 MavMAIN kernel: obfsproxy993 IN=eth0 OUT=br0 MAC=04:92:26:80:8b:08:00:01:5c:97:f8:45:08:00 SRC=72.143.234.93 DST=10.1.1.11 LEN=60 TOS=0x10 PREC=0x40 TTL=53 ID=0 DF PROTO=TCP SPT=3249 DPT=993 WINDOW=65535 RES=0x00 SYN URGP=0 MARK=0x8000000
Nov 21 22:04:15 MavMAIN ovpn-server1[2470]: 10.1.1.11:59686 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Nov 21 22:04:15 MavMAIN ovpn-server1[2470]: 10.1.1.11:59686 TLS Error: TLS handshake failed
Nov 21 22:04:15 MavMAIN ovpn-server1[2470]: 10.1.1.11:59686 Fatal TLS error (check_tls_errors_co), restarting

 

[Diamond67]

AC68U here. Although I have daily automatic reboots every morning at 4:40AM like I always had, this latest update make the Wifi unreachable every morning when we get up. I have to manually reboot the AC68U. I guess I should go back. The only thing I added after the new update was FlexQOS. That’s it.

I have AC68U too. And got serious Wi-Fi problems immediately after updating to 386.12_2. I had to reboot the router or manually restart Wi-Fi service at least once a day (sometimes twice) because Wi-Fi just died all the time.

I went back to fw 386.12_0 and my Wi-Fi problems were gone right away. Not a single problem since. Wi-Fi and router uptime 3 days 5 hours now without any trouble. Somehow this was not possible with 386.12_2. Don't know why.

Anyway, seems that I have to run some tests with another fw because 386.12_4 is out.

edit: updated to fw 386.12_4. Fingers crossed.

 

[natewin]

Have noticed the following with 386.12_2 and 386.12_4 on an RT-AC88U

• AC88U Factory reset now applies wpa2 security to the default networks with password asuswifi0123. The wireless networks are no longer OPEN after a factory reset.
• I can add the AC88U as a node, but after adding as a node I can't update firmware or log in to 'switch control' from the node management page. The password that matches my main router will not work. I've tried admin/admin that won't work either. I've also tried admin/mypassword no luck. To update this node I had to remove it, log in with defaults, update firmware, add back as node. Even going through this again with the _4 firmware I can't admin the node.
• I also have a AC86U node, it is working as expected. I can update firmware and change 'switch control' settings with normal main router login credentials.
• Main router is a AX86U

I understand the node code is not controlled by Merlin. I don't mind reporting this as a bug, but I don't know the proper channels to do so.

 

[RKaniec]

Hallo,

I use two routers RT-AC68U (as a backup for each other) and I upgraded both of them from 386.12 to 386.12_2 on Monday.

With the first upgraded router everything went well (hardware version V3, production year 2020). The router is working on 386.12_2 without any problems.

Then I upgraded the second router and it stopped working (hardware version E1, production year 2017). Watching the LEDs I saw that it was restarting in a loop. The WiFi LEDs however didn't light up at all.
I tried to login to the router using a cable but couldn't connect, the login screen didn't show up.
Next I tried to revert to the 386.12 using the ASUS Firmware Restoration tool, version 2.1.0.3 as indicated for this model, but the firmware upload (twice) ended with an error. So I repeated the upload with the original newest ASUS firmware 300438651665, but also this time the upload ended with an error. At the end I tried to restore the factory settings, also without success.

Do you see any chance to save this router?
I will appreciate your help very much.

With best regards,
Robert

 

[TnF]

Not sure if it's a known issue. I've updated my RT-AC68U from 386.12 (was working flawlessly) to 386.12_2 a few days ago, and i keep getting Wi-Fi devices booted off all together after a day or so (it seems), both radios (2.4ghz and 5ghz) stay still up but you are unable to re-authenticate to reconnect. Only rebooting the router fixes it until it happens again. I was about to downgrade (not sure if it will even allow me), but i saw 386.12_4 was released today so i updated to that instead to see if it fixes it (change log has no mention of this issue).

Here's my log on 386.12_2 just before i rebooted (due to the issue happening) and updating to 386.12_4: https://pastebin.com/HaDn99d3

edit: now reading the posts it looks like i am not the only one with 386.12_2 wifi issues...is it related to openvpn problem though? cause i don't use it

 

[KrypteX]

@TnF I'm investigating where the WiFi issues come from on 386.12_2. I suspect the WDS fixes on AC68U / AC88U or the upgrade to OpenSSL 1.1.1v / w
I don't think OpenVPN 2.6.7/8 has anything to do with it.

It may somehow also be caused by the dcd crash fix. Do you have Trend Micro enabled?

 

[bibikalka]

Not sure if it's a known issue. I've updated my RT-AC68U from 386.12 (was working flawlessly) to 386.12_2 a few days ago, and i keep getting Wi-Fi devices booted off all together after a day or so (it seems), both radios (2.4ghz and 5ghz) stay still up but you are unable to re-authenticate to reconnect. Only rebooting the router fixes it until it happens again. I was about to downgrade (not sure if it will even allow me), but i saw 386.12_4 was released today so i updated to that instead to see if it fixes it (change log has no mention of this issue).

Here's my log on 386.12_2 just before i rebooted (due to the issue happening) and updating to 386.12_4: https://pastebin.com/HaDn99d3

edit: now reading the posts it looks like i am not the only one with 386.12_2 wifi issues...is it related to openvpn problem though? cause i don't use it

I had similar issues with plain 386.12 as well! The issue would usually occur after ~3+ days of operations, sometimes a couple of weeks would pass.

Implemented nightly reboots - so it's refreshed