What's new

Release Asuswrt-Merlin 386.12 is now available for AC models

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Status
Not open for further replies.
RT-AC86U. 386.12_4. 5Ghz WiFi is intermittently dropping out. Should I back out back to 12 (_0) or is there another fix. Didn't read all the pages, but I see others reporting WiFi stability issues. (it died again trying to post this)
I had same problems on ac86 - 5ghz would horribly slow down every several (3-5) days. I set the channel to 49 and haven't seen slowdowns yet (7 days since fixing the channel).

Had that problem on _0 as well, so I don't think downgrade will solve anything.
 
I've been having some random latency spikes while gaming(wired) and if I leave a ping running to the router I can see those ocasional spikes. (20-50ms random spike).

Ac86u connected directly to ONT. 500/100 fiber.
386.12 factory reset, basic setup with only wifi settings done.

The best way to make it spike fast is to have a torrent client running, even super limited to 1/1mb is enough. But it also happens just gaming normally, just less frequently.
To fix it I tried multiple things, and it seems to be related to hardware acceleration, as enabling cake fixes it. But soo does enabling aiprotection/qos/trend micro services.

After I reached that conclusion I tried manually disabling runner and fc. Disabling runner alone fixes it.
 
Good sleuthing!

Any reason why you're not on the latest release of 386.12?
 
Good sleuthing!

Any reason why you're not on the latest release of 386.12?

I'm on latest 386.12_4. Seems strange enabling aiprotection or qos fixes it. As soon as I go to privacy and press Withdraw ocasional latency spikes come back.
Manually disabling runner using ssh fixes it. No need to run trend micro crap.

Edit: Just tried stock firmware without factory reset for a quick test. Exact same behavior... Something funky goin on with runner / trend micro.
I'm just going to run runner disable for now with merlin firmware.

Should I report this to asus since it also happens with stock firmware?

Edit: Can this be a cpu idle issue and not a runner issue? It happens with relatively low loads but AIprotection increases cpu usage so does disabling runner.
I don't know how to disable those features soo I can't test it properly.
 
Last edited:
If you're toggling settings on/off, flashing stock/RMerlin, and not rebooting afterward, you're not really testing anything authentically, or, at least in a way that is useful to troubleshoot for a solution.

Pick a firmware. Flash it. Reset to factory defaults using the appropriate method for your router from the link below.


Perform a minimal and manual configuration to secure the router and connect to your ISP. Do NOT use a saved backup config file. Do NOT insert any USB devices (particularly if one was used for amtm/scripts).

If the issue is still present, that may be worth reporting to Asus (after repeating the steps above on stock Asus firmware, of course).

As it stands, this may just be a slightly confused router with all the flashing and toggling of settings that you've been putting it through.
 
I had same problems on ac86 - 5ghz would horribly slow down every several (3-5) days. I set the channel to 49 and haven't seen slowdowns yet (7 days since fixing the channel).

Had that problem on _0 as well, so I don't think downgrade will solve anything.

Do you mean the control channel on wireless/general? I don't have 49. I have 44, 48, 52 around that. I've set it to 60 now as that didn't have any neighbours using it. It was on 44 which was congested.
 
Dec 24 13:52:46 kernel: dcd[1444]: unhandled level 3 translation fault (11) at 0x00000000, esr 0x92000007
Dec 24 13:52:46 kernel: pgd = ffffffc01287b000
Dec 24 13:52:46 kernel: [00000000] *pgd=00000000190ef003, *pud=00000000190ef003, *pmd=0000000013371003, *pte=0000000000000000
Dec 24 13:52:46 kernel: CPU: 1 PID: 1444 Comm: dcd Tainted: P O 4.1.27 #2
Dec 24 13:52:46 kernel: Hardware name: Broadcom-v8A (DT)
Dec 24 13:52:46 kernel: task: ffffffc0133b7500 ti: ffffffc01330c000 task.ti: ffffffc01330c000
Dec 24 13:52:46 kernel: PC is at 0xf733ff44
Dec 24 13:52:46 kernel: LR is at 0x1dce0
Dec 24 13:52:46 kernel: pc : [<00000000f733ff44>] lr : [<000000000001dce0>] pstate: 600b0010
Dec 24 13:52:46 kernel: sp : 00000000ffeb8228
Dec 24 13:52:46 kernel: x12: 00000000000a2050
Dec 24 13:52:46 kernel: x11: 00000000f65ff024 x10: 00000000000a23c4
Dec 24 13:52:46 kernel: x9 : 00000000f65ff6cc x8 : 00000000000a287c
Dec 24 13:52:46 kernel: x7 : 00000000f65ff704 x6 : 00000000000a2876
Dec 24 13:52:46 kernel: x5 : 0000000000000000 x4 : 00000000f65ff6b0
Dec 24 13:52:46 kernel: x3 : 0000000000000000 x2 : 00000000ffeb8204
Dec 24 13:52:46 kernel: x1 : 000000000007d72e x0 : 0000000000000000
Dec 24 13:52:46 kernel: potentially unexpected fatal signal 11.
Dec 24 13:52:46 kernel: CPU: 1 PID: 1444 Comm: dcd Tainted: P O 4.1.27 #2
Dec 24 13:52:46 kernel: Hardware name: Broadcom-v8A (DT)
Dec 24 13:52:46 kernel: task: ffffffc0133b7500 ti: ffffffc01330c000 task.ti: ffffffc01330c000
Dec 24 13:52:46 kernel: PC is at 0xf733ff44
Dec 24 13:52:46 kernel: LR is at 0x1dce0
Dec 24 13:52:46 kernel: pc : [<00000000f733ff44>] lr : [<000000000001dce0>] pstate: 600b0010
Dec 24 13:52:46 kernel: sp : 00000000ffeb8228
Dec 24 13:52:46 kernel: x12: 00000000000a2050
Dec 24 13:52:46 kernel: x11: 00000000f65ff024 x10: 00000000000a23c4
Dec 24 13:52:46 kernel: x9 : 00000000f65ff6cc x8 : 00000000000a287c
Dec 24 13:52:46 kernel: x7 : 00000000f65ff704 x6 : 00000000000a2876
Dec 24 13:52:46 kernel: x5 : 0000000000000000 x4 : 00000000f65ff6b0
Dec 24 13:52:46 kernel: x3 : 0000000000000000 x2 : 00000000ffeb8204
Dec 24 13:52:46 kernel: x1 : 000000000007d72e x0 : 0000000000000000
Dec 24 14:00:05 Skynet: [#] 462503 IPs (+0) -- 18661 Ranges Banned (+0) || 3875 Inbound -- 429 Outbound Connections Blocked! [save] [5s]
Dec 24 14:00:30 kernel: dcd[6164]: unhandled level 3 translation fault (11) at 0x00000000, esr 0x92000007
Dec 24 14:00:30 kernel: pgd = ffffffc0166ca000
Dec 24 14:00:30 kernel: [00000000] *pgd=00000000095b9003, *pud=00000000095b9003, *pmd=0000000002696003, *pte=0000000000000000
Dec 24 14:00:30 kernel: CPU: 1 PID: 6164 Comm: dcd Tainted: P O 4.1.27 #2
Dec 24 14:00:30 kernel: Hardware name: Broadcom-v8A (DT)
Dec 24 14:00:30 kernel: task: ffffffc01716ebc0 ti: ffffffc014214000 task.ti: ffffffc014214000
Dec 24 14:00:30 kernel: PC is at 0xf7041f44
Dec 24 14:00:30 kernel: LR is at 0x1dce0
Dec 24 14:00:30 kernel: pc : [<00000000f7041f44>] lr : [<000000000001dce0>] pstate: 600b0010
Dec 24 14:00:30 kernel: sp : 00000000ffdb4478
Dec 24 14:00:30 kernel: x12: 00000000000a2050
Dec 24 14:00:30 kernel: x11: 00000000f62ff024 x10: 00000000000a23c4
Dec 24 14:00:31 kernel: x9 : 00000000f62ff6cc x8 : 00000000000a287c
Dec 24 14:00:31 kernel: x7 : 00000000f62ff704 x6 : 00000000000a2876
Dec 24 14:00:31 kernel: x5 : 0000000000000000 x4 : 00000000f62ff6b0
Dec 24 14:00:31 kernel: x3 : 0000000000000000 x2 : 00000000ffdb4454
Dec 24 14:00:31 kernel: x1 : 000000000007d72e x0 : 0000000000000000
Dec 24 14:00:31 kernel: potentially unexpected fatal signal 11.
Dec 24 14:00:31 kernel: CPU: 1 PID: 6164 Comm: dcd Tainted: P O 4.1.27 #2
Dec 24 14:00:31 kernel: Hardware name: Broadcom-v8A (DT)
Dec 24 14:00:31 kernel: task: ffffffc01716ebc0 ti: ffffffc014214000 task.ti: ffffffc014214000
Dec 24 14:00:31 kernel: PC is at 0xf7041f44
Dec 24 14:00:31 kernel: LR is at 0x1dce0
Dec 24 14:00:31 kernel: pc : [<00000000f7041f44>] lr : [<000000000001dce0>] pstate: 600b0010
Dec 24 14:00:31 kernel: sp : 00000000ffdb4478
Dec 24 14:00:31 kernel: x12: 00000000000a2050
Dec 24 14:00:31 kernel: x11: 00000000f62ff024 x10: 00000000000a23c4
Dec 24 14:00:31 kernel: x9 : 00000000f62ff6cc x8 : 00000000000a287c
Dec 24 14:00:31 kernel: x7 : 00000000f62ff704 x6 : 00000000000a2876
Dec 24 14:00:31 kernel: x5 : 0000000000000000 x4 : 00000000f62ff6b0
Dec 24 14:00:31 kernel: x3 : 0000000000000000 x2 : 00000000ffdb4454
Dec 24 14:00:31 kernel: x1 : 000000000007d72e x0 : 0000000000000000
Dec 24 14:15:12 kernel: dcd[8494]: unhandled level 3 translation fault (11) at 0x00000000, esr 0x92000007
Dec 24 14:15:12 kernel: pgd = ffffffc0096d2000
Dec 24 14:15:12 kernel: [00000000] *pgd=00000000120fe003, *pud=00000000120fe003, *pmd=0000000016ba9003, *pte=0000000000000000
Dec 24 14:15:12 kernel: CPU: 1 PID: 8494 Comm: dcd Tainted: P O 4.1.27 #2
Dec 24 14:15:12 kernel: Hardware name: Broadcom-v8A (DT)
Dec 24 14:15:12 kernel: task: ffffffc014212100 ti: ffffffc01640c000 task.ti: ffffffc01640c000
Dec 24 14:15:12 kernel: PC is at 0xf7391f44
Dec 24 14:15:12 kernel: LR is at 0x1dce0
Dec 24 14:15:12 kernel: pc : [<00000000f7391f44>] lr : [<000000000001dce0>] pstate: 600b0010
Dec 24 14:15:12 kernel: sp : 00000000ffe4e7a8
Dec 24 14:15:12 kernel: x12: 00000000000a2050
Dec 24 14:15:12 kernel: x11: 00000000f66ff024 x10: 00000000000a23c4
Dec 24 14:15:12 kernel: x9 : 00000000f66ff6cc x8 : 00000000000a287c
Dec 24 14:15:12 kernel: x7 : 00000000f66ff704 x6 : 00000000000a2876
Dec 24 14:15:12 kernel: x5 : 0000000000000000 x4 : 00000000f66ff6b0
Dec 24 14:15:12 kernel: x3 : 0000000000000000 x2 : 00000000ffe4e784
Dec 24 14:15:12 kernel: x1 : 000000000007d72e x0 : 0000000000000000
Dec 24 14:15:12 kernel: potentially unexpected fatal signal 11.
Dec 24 14:15:12 kernel: CPU: 1 PID: 8494 Comm: dcd Tainted: P O 4.1.27 #2
Dec 24 14:15:12 kernel: Hardware name: Broadcom-v8A (DT)
Dec 24 14:15:12 kernel: task: ffffffc014212100 ti: ffffffc01640c000 task.ti: ffffffc01640c000
Dec 24 14:15:12 kernel: PC is at 0xf7391f44
Dec 24 14:15:12 kernel: LR is at 0x1dce0
Dec 24 14:15:12 kernel: pc : [<00000000f7391f44>] lr : [<000000000001dce0>] pstate: 600b0010
Dec 24 14:15:12 kernel: sp : 00000000ffe4e7a8
Dec 24 14:15:12 kernel: x12: 00000000000a2050
Dec 24 14:15:12 kernel: x11: 00000000f66ff024 x10: 00000000000a23c4
Dec 24 14:15:12 kernel: x9 : 00000000f66ff6cc x8 : 00000000000a287c
Dec 24 14:15:12 kernel: x7 : 00000000f66ff704 x6 : 00000000000a2876
Dec 24 14:15:12 kernel: x5 : 0000000000000000 x4 : 00000000f66ff6b0
Dec 24 14:15:12 kernel: x3 : 0000000000000000 x2 : 00000000ffe4e784
Dec 24 14:15:12 kernel: x1 : 000000000007d72e x0 : 0000000000000000
Dec 24 14:30:37 kernel: dcd[12124]: unhandled
 
Last edited:
Dec 24 15:00:05 Skynet: [#] 462503 IPs (+0) -- 18661 Ranges Banned (+0) || 4276 Inbound -- 459 Outbound Connections Blocked! [save] [5s]

Dec 24 15:13:27 ovpn-client1[1892]: AEAD Decrypt error: bad packet ID (may be a replay): [ #5641232 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings

Dec 24 15:13:27 ovpn-client1[1892]: AEAD Decrypt error: bad packet ID (may be a replay): [ #5641233 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings

Dec 24 15:13:27 ovpn-client1[1892]: AEAD Decrypt error: bad packet ID (may be a replay): [ #5641234 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings

Dec 24 15:13:27 ovpn-client1[1892]: AEAD Decrypt error: bad packet ID (may be a replay): [ #5641321 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings

Dec 24 15:13:27 ovpn-client1[1892]: AEAD Decrypt error: bad packet ID (may be a replay): [ #5641318 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings

Dec 24 15:13:27 ovpn-client1[1892]: AEAD Decrypt error: bad packet ID (may be a replay): [ #5641319 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings

Dec 24 15:13:27 ovpn-client1[1892]: AEAD Decrypt error: bad packet ID (may be a replay): [ #5641320 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings

Dec 24 15:13:27 ovpn-client1[1892]: AEAD Decrypt error: bad packet ID (may be a replay): [ #5641323 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings

Dec 24 15:13:27 ovpn-client1[1892]: AEAD Decrypt error: bad packet ID (may be a replay): [ #5641324 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings

Dec 24 15:13:27 ovpn-client1[1892]: AEAD Decrypt error: bad packet ID (may be a replay): [ #5641325 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings

Dec 24 15:13:27 ovpn-client1[1892]: AEAD Decrypt error: bad packet ID (may be a replay): [ #5641326 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings

Dec 24 15:13:27 ovpn-client1[1892]: AEAD Decrypt error: bad packet ID (may be a replay): [ #5641327 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings

Dec 24 15:13:27 ovpn-client1[1892]: AEAD Decrypt error: bad packet ID (may be a replay): [ #5641328 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings

Dec 24 15:13:27 ovpn-client1[1892]: AEAD Decrypt error: bad packet ID (may be a replay): [ #5641329 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings

Dec 24 15:13:27 ovpn-client1[1892]: AEAD Decrypt error: bad packet ID (may be a replay): [ #5641330 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings

Dec 24 15:13:27 ovpn-client1[1892]: AEAD Decrypt error: bad packet ID (may be a replay): [ #5641331 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings

Dec 24 15:13:27 ovpn-client1[1892]: AEAD Decrypt error: bad packet ID (may be a replay): [ #5641332 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings

Dec 24 15:13:27 ovpn-client1[1892]: AEAD Decrypt error: bad packet ID (may be a replay): [ #5641333 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings

Dec 24 15:13:27 ovpn-client1[1892]: AEAD Decrypt error: bad packet ID (may be a replay): [ #5641334 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings

Dec 24 15:13:27 ovpn-client1[1892]: AEAD Decrypt error: bad packet ID (may be a replay): [ #5641335 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings

Dec 24 15:13:27 ovpn-client1[1892]: AEAD Decrypt error: bad packet ID (may be a replay): [ #5641336 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings

Dec 24 15:13:27 ovpn-client1[1892]: AEAD Decrypt error: bad packet ID (may be a replay): [ #5641337 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings

Dec 24 15:13:27 ovpn-client1[1892]: AEAD Decrypt error: bad packet ID (may be a replay): [ #5641338 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings

Dec 24 15:13:27 ovpn-client1[1892]: AEAD Decrypt error: bad packet ID (may be a replay): [ #5641322 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings

Dec 24 15:13:27 ovpn-client1[1892]: AEAD Decrypt error: bad packet ID (may be a replay): [ #5641371 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings

Dec 24 15:13:27 ovpn-client1[1892]: AEAD Decrypt error: bad packet ID (may be a replay): [ #5641339 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings

Dec 24 15:13:27 ovpn-client1[1892]: AEAD Decrypt error: bad packet ID (may be a replay): [ #5641340 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings

Dec 24 15:13:27 ovpn-client1[1892]: AEAD Decrypt error: bad packet ID (may be a replay): [ #5641341 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings

Dec 24 15:13:27 ovpn-client1[1892]: AEAD Decrypt error: bad packet ID (may be a replay): [ #5641342 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings

Dec 24 15:13:27 ovpn-client1[1892]: AEAD Decrypt error: bad packet ID (may be a replay): [ #5641343 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings

Dec 24 15:13:27 ovpn-client1[1892]: AEAD Decrypt error: bad packet ID (may be a replay): [ #5641372 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings

Dec 24 15:13:27 ovpn-client1[1892]: AEAD Decrypt error: bad packet ID (may be a replay): [ #5641373 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings

Dec 24 15:13:27 ovpn-client1[1892]: AEAD Decrypt error: bad packet ID (may be a replay): [ #5641374 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings

Dec 24 15:13:27 ovpn-client1[1892]: AEAD Decrypt error: bad packet ID (may be a replay): [ #5641375 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings
 
Last edited:
Been running 386.12_4 for the past week and its been solid. Had a few ASD crashes the first day but they stopped. I've got all of AiProtection enabled but don't have any scripts or VPN running. The httpd server will crash sometimes if i'm logged in and the cpu cores are maxed. And with AiProtection i only get ~850m instead of the full 940m I do with it off.
 
Edit: Just tried stock firmware without factory reset for a quick test. Exact same behavior... Something funky goin on with runner / trend micro.
I'm just going to run runner disable for now with merlin firmware.

Should I report this to asus since it also happens with stock firmware?
Yes indeed! That is our best chance of getting them to fix it in the proprietary parts of the code.

The report feature is under "Administration/Feedback" - describe what you did and what the problem is- in the free-text field, and remember to check "attach logs" so they can use it to problem-solve.
 
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...

Code:
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]

Hi gmy

Yes, i have this "evict flow" kernel message in my RT-AC86U syslog. Quite annoying. If you raise the verbose level to warning(?) then you won't see it, but I guess other info lvl msg wont appear either :/

Unfortunately I haven't found any other solution for it so far
 
RT-AC86U. 386.12_4. 5Ghz WiFi is intermittently dropping out. Should I back out back to 12 (_0) or is there another fix. Didn't read all the pages, but I see others reporting WiFi stability issues. (it died again trying to post this)


BTW, after my radio has stopped working (as it normally does very frequently these days) and I try to (unsuccessfully) connect to the router with a wireless device, General log shows lines like this (MAC address edited):

Code:
Dec 27 16:57:48 syslog: wlceventd_proc_event(530): eth2: Auth  A1:B2:C3:D4:E5:F6, status: Successful (0), rssi:0
Dec 27 16:57:48 syslog: wlceventd_proc_event(559): eth2: Assoc  A1:B2:C3:D4:E5:F6, status: Successful (0), rssi:0
Dec 27 16:57:58 syslog: wlceventd_proc_event(494): eth2: Deauth_ind  A1:B2:C3:D4:E5:F6, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3), rssi:0


I found an old thread concerning the same kinda problem:



There were some tips about tweaking certain settings (from Wireless - Professional) like

Disabling "Enable WMM APSD"
or lowering the "Beacon Interval" to 90 (default is 100ms).

I just disabled my WMM APSD, which seems to be some sort of "Automatic Power Save Delivery". Let's see if it changes something or not.

P.S. Tweaking WMM APSD setting reboots the radio, so don't touch it if you have active data transfers going on atm.
 
BTW, after my radio has stopped working (as it normally does very frequently these days) and I try to (unsuccessfully) connect to the router with a wireless device, General log shows lines like this (MAC address edited):

Code:
Dec 27 16:57:48 syslog: wlceventd_proc_event(530): eth2: Auth  A1:B2:C3:D4:E5:F6, status: Successful (0), rssi:0
Dec 27 16:57:48 syslog: wlceventd_proc_event(559): eth2: Assoc  A1:B2:C3:D4:E5:F6, status: Successful (0), rssi:0
Dec 27 16:57:58 syslog: wlceventd_proc_event(494): eth2: Deauth_ind  A1:B2:C3:D4:E5:F6, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3), rssi:0


I found an old thread concerning the same kinda problem:



There were some tips about tweaking certain settings (from Wireless - Professional) like

Disabling "Enable WMM APSD"
or lowering the "Beacon Interval" to 90 (default is 100ms).

I just disabled my WMM APSD, which seems to be some sort of "Automatic Power Save Delivery". Let's see if it changes something or not.

P.S. Tweaking WMM APSD setting reboots the radio, so don't touch it if you have active data transfers going on atm.

You will definitely see something. Decreased battery life on all your devices.

Have you tried "forgetting" the network from the troublesome device and re-associate?

FWIW and IMHO, people (appear to) have problems for a few key reasons:

1) Hardware failure/failing
2) Spectrum noise, congestion or a combination of both (something very specific to your location)
3) Not following the recommended process & settings
4) Making too many changes in too short time, expecting instant results
5) A really cheap IOT device that just sucks

IMHO it is almost never the device software/firmware once it's reached maturity: (i.e. all WiFi5/AC devices) - with the exception of #1.

I might be naive or lucky - or both but once I set fixed channels, set the professional settings - especially Airtime Fairness - Off - and avoided 2.4GHz as much as possible.

I have devices in my wireless log with connection times in months.

Maybe I'm lucky with my two RT-AC86u, and my past 2 68u, and my Original 66u Dark Knight.

My recommendation is a systematic troubleshooting approach. Its slow but its your best shot.

YMMV of course.
 
You will definitely see something. Decreased battery life on all your devices.

Have you tried "forgetting" the network from the troublesome device and re-associate?

FWIW and IMHO, people (appear to) have problems for a few key reasons:

1) Hardware failure/failing
2) Spectrum noise, congestion or a combination of both (something very specific to your location)
3) Not following the recommended process & settings
4) Making too many changes in too short time, expecting instant results
5) A really cheap IOT device that just sucks

IMHO it is almost never the device software/firmware once it's reached maturity: (i.e. all WiFi5/AC devices) - with the exception of #1.

I might be naive or lucky - or both but once I set fixed channels, set the professional settings - especially Airtime Fairness - Off - and avoided 2.4GHz as much as possible.

I have devices in my wireless log with connection times in months.

Maybe I'm lucky with my two RT-AC86u, and my past 2 68u, and my Original 66u Dark Knight.

My recommendation is a systematic troubleshooting approach. Its slow but its your best shot.

YMMV of course.

Battery/power consumption is not a problem, expecially with laptops connected to AC power. Or mobile phones which are offline (Wi-fi) almost all the time.

Hardware failure/failing is one option. But rebooting the radio of the router (or just disabling/enabling radio from the settings) fixes the wireless connection. So, could it be a hardware problem with radio chip of the router?
 
Battery/power consumption is not a problem, expecially with laptops connected to AC power. Or mobile phones which are offline (Wi-fi) almost all the time.

Hardware failure/failing is one option. But rebooting the radio of the router (or just disabling/enabling radio from the settings) fixes the wireless connection. So, could it be a hardware problem with radio chip of the router?
Hard to say, just keep in mind toggling the radio may be masking an issue with clients. Remember the client is the boss. It initiates the connection. When the issue happens, do you have a spare device you can use to try to connect while issue is occurring? Not knowing your use case or specific nuances, you need some repeatable tasks with trial and error.

Good luck
 
When the issue happens, do you have a spare device you can use to try to connect while issue is occurring?

Sometimes when I have been using WiFi for example with my mobile phone for a while and then at the same time (when the connection still works OK with my phone) try to connect with my laptop the WiFi won't work at all. Then if I disconnect the WiFi of my mobile phone and try to reconnect again, the connection is lost with the phone as well.

Sometimes the current wifi connection for example with laptop may suddenly fail. And you can reconnect only after you have logged into the router with wired connection (PC) and restarted the WiFi (scMerlin, 4. to restart the Wifi service) or just disabled/enabled radio from Merlin GUI. After that the WiFi works OK again.
 
Do you mean the control channel on wireless/general? I don't have 49. I have 44, 48, 52 around that. I've set it to 60 now as that didn't have any neighbours using it. It was on 44 which was congested.
Yes, I meant the control channel and it was 48, not 49 as I initially remembered. But interestingly, I don't have anything between 48 and 149.
I don't think that congestion was the culprit in my case - I don't get any 5ghz signals apart from my own.
And I haven't seen the slowdowns since fixing the control channel to 48.
 
BTW, after my radio has stopped working (as it normally does very frequently these days) and I try to (unsuccessfully) connect to the router with a wireless device, General log shows lines like this (MAC address edited):

Code:
Dec 27 16:57:48 syslog: wlceventd_proc_event(530): eth2: Auth  A1:B2:C3:D4:E5:F6, status: Successful (0), rssi:0
Dec 27 16:57:48 syslog: wlceventd_proc_event(559): eth2: Assoc  A1:B2:C3:D4:E5:F6, status: Successful (0), rssi:0
Dec 27 16:57:58 syslog: wlceventd_proc_event(494): eth2: Deauth_ind  A1:B2:C3:D4:E5:F6, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3), rssi:0


I found an old thread concerning the same kinda problem:



There were some tips about tweaking certain settings (from Wireless - Professional) like

Disabling "Enable WMM APSD"
or lowering the "Beacon Interval" to 90 (default is 100ms).

I just disabled my WMM APSD, which seems to be some sort of "Automatic Power Save Delivery". Let's see if it changes something or not.

P.S. Tweaking WMM APSD setting reboots the radio, so don't touch it if you have active data transfers going on atm.

This is client device caused, usually crappy iphones.
 
This is client device caused, usually crappy iphones.

I don't use iPhones. And when the problem kicks in it seems to affect all my wireless client devices, normally a few laptop computers and Android phones. After rebooting the radio of the router the WiFi and all wireless devices work OK.
 
Have the latest firmware 386.12_4 for a few weeks now on AC86u. Running AiProtection and TM - have to. There is an AiMesh node connected via 5 Ghz band. About ~20 devices Max at various times. The router is on UPS, so no power supply reboots.

The main router is cron rebooted nightly at 4:05 am. There are occasional crashes on busy WiFi days (week-ends), but the router quickly reboots itself (quicker than an explicit reboot!) such that by the time people notice lack of Internet it's already back 🤣 I can work with that!!!

When AiProtection/TM is off, the router is far more stable.

While nightly reboots may seem ugly to some - I say, do it. My WiFi does not have a chance to disappear after a few days - it does not run for that long.

Was looking at the AX86U Pro NewEgg deal now for $200, and it says this:
Commercial-grade Security Anywhere – Protect your home network with AiProtection Pro, powered by Trend Micro. 🤣🤣🤣🤣🤣🤣🤣

Maybe AC86U TM engine is flaky because it is not *PRO* ???

Here is an example, non 4am reboots are crash-reboot cycles, which also mess up clock conservation. 12:45 time stamps are not real below.

Code:
Jan  3 04:05:06 kernel: klogd started: BusyBox v1.25.1 (2023-11-21 22:37:39 EST)
Jan  3 04:06:25 kernel: klogd started: BusyBox v1.25.1 (2023-11-21 22:37:39 EST)
Jan  3 04:06:26 kernel: klogd started: BusyBox v1.25.1 (2023-11-21 22:37:39 EST)
Jan  4 04:05:05 kernel: klogd started: BusyBox v1.25.1 (2023-11-21 22:37:39 EST)
Jan  5 04:05:05 kernel: klogd started: BusyBox v1.25.1 (2023-11-21 22:37:39 EST)
Jan  5 04:06:21 kernel: klogd started: BusyBox v1.25.1 (2023-11-21 22:37:39 EST)
Jan  6 04:05:06 kernel: klogd started: BusyBox v1.25.1 (2023-11-21 22:37:39 EST)
Jan  6 04:06:22 kernel: klogd started: BusyBox v1.25.1 (2023-11-21 22:37:39 EST)
Jan  6 12:45:00 kernel: klogd started: BusyBox v1.25.1 (2023-11-21 22:37:39 EST)
Jan  6 16:50:32 kernel: klogd started: BusyBox v1.25.1 (2023-11-21 22:37:39 EST)
Jan  7 04:05:07 kernel: klogd started: BusyBox v1.25.1 (2023-11-21 22:37:39 EST)
Jan  7 04:06:32 kernel: klogd started: BusyBox v1.25.1 (2023-11-21 22:37:39 EST)
Jan  7 07:23:18 kernel: klogd started: BusyBox v1.25.1 (2023-11-21 22:37:39 EST)
Jan  7 12:45:00 kernel: klogd started: BusyBox v1.25.1 (2023-11-21 22:37:39 EST)
Jan  7 17:08:53 kernel: klogd started: BusyBox v1.25.1 (2023-11-21 22:37:39 EST)
Jan  8 04:05:05 kernel: klogd started: BusyBox v1.25.1 (2023-11-21 22:37:39 EST)
Jan  8 04:06:20 kernel: klogd started: BusyBox v1.25.1 (2023-11-21 22:37:39 EST)
Jan  8 04:06:20 kernel: klogd started: BusyBox v1.25.1 (2023-11-21 22:37:39 EST)
 
Status
Not open for further replies.

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top