You can rollback to .13, but if you notice any odd behavior just factory reset .13.The issue persists after factory reset and manual config.
Is it safe to rollback from 14 to 13 (with a factory reset)? I need my router in working condition and it was working well before upgrading to 14.
adjust 5 ghz manually on a channel ex: 157 and dont use smart connectI will reset and cross fingers
I would reset anyway because the formatting of the DHCP static list changed going from 13 to 14 (extra field for DNS). Might not work properly going from 14 to 13 with the extra characters.You can rollback to .13, but if you notice any odd behavior just factory reset .13.
The log entries are from having Auto channel selection on the 5Ghz WiFi. Choose a specific channel and observe.What could cause this?
Asuswrt-Merlin 384.13_2 (RT-AC87U and RT-AC3200), and 384.14 (other models) are now available.
Jan 1st: 384.14_2 is available for the RT-AC68U, RTAC88U/3100/5300 and RT-AC86U, addressing a few issues specific to these models. Changes since 384.14:
Code:- FIXED: Missing cifs kernel module - FIXED: stubby was linked with OpenSSL 1.0 instead of 1.1 - FIXED: some routers were reporting the Internet connection being disconnected. If you were affected and you had flashed a customized bootloader, then please reflash your original bootloader, as your modded bootloader is invalid, and other potential issues may appear over time. - FIXED: Random traffic spikes logged in Traffic Monitor (regression from 384_81351)
Dirty upgrade my ASUS RT-AC3100 from 384.13 to 384.14 and started to get internet disconnection every 30-40 minutes. Only a reboot will fix this. According to the release notes, 384.14_2 fixes this issue and, after upgrading, I still have the same issue.
Please be nice (first time in this forum) since I'm not use to this place etiquette yet (and, although I have a technical background, I'm not familiarized with the inner workings of Merlin).
Any ideas how to fix this? Is it a known issue? Right now, I'm about to be hanged by my family for the constant internet interruptions.
I just tried to update my AC86U to today’s 384.14-2, and something catastrophic has happened. I get a red WAN light, but more importantly no router interface or even WiFi AP.
dropbear is loaded, so I was able to SSH in from my wired PC. ‘dmesg’ does show bad blocks on the nand/jffs, but would that really prevent the whole system from booting?
I was also using USB swap for amtm/diversion/etc but USB in or out doesn’t make a difference.
Prior to today, it had been up for a couple of weeks with no issues. I did see those ipv6 errors (“Failed to send DHCPV6 message”) in the logs prior to upgrading, which was new to me, but I don’t know that it’s relevant (I don’t think my Fios has it yet and I may have set the router to look for one)
I did try a hard reset by pressing the reset button while online, but that didn’t actually do anything. Held it in while power cycling; the power light did start flashing, but it didn’t seem like it was doing anything else; rebooted normally and got right back to where I was.
Otherwise, I don’t know what other info is relevant beyond upgrading from a couple of versions ago (384.12 I think?). Anything I can do to try and recover?
Going from 384.13 to the latest 384.14 release, recommended reset of the router, opinions? 13 is just so stable.
I get that too but my reason is slightly different:
Code:Jan 2 09:50:18 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth6: Deauth_ind 84:AD:8D:9B:B2:38, status: 0, reason: Disassociated due to inactivity (4) Jan 2 09:50:18 wlceventd: WLCEVENTD wlceventd_proc_event(401): eth6: Disassoc 84:AD:8D:9B:B2:38, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8) Jan 2 09:51:31 wlceventd: WLCEVENTD wlceventd_proc_event(420): eth6: Auth 84:AD:8D:9B:B2:38, status: 0, reason: d11 RC reserved (0) Jan 2 09:51:31 wlceventd: WLCEVENTD wlceventd_proc_event(430): eth6: ReAssoc 84:AD:8D:9B:B2:38, status: 0, reason: d11 RC reserved (0) Jan 2 09:53:12 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth6: Deauth_ind 84:AD:8D:9B:B2:38, status: 0, reason: Class 3 frame received from nonassociated station (7) Jan 2 09:53:12 wlceventd: WLCEVENTD wlceventd_proc_event(401): eth6: Disassoc 84:AD:8D:9B:B2:38, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8) Jan 2 09:53:48 wlceventd: WLCEVENTD wlceventd_proc_event(420): eth6: Auth 84:AD:8D:9B:B2:38, status: 0, reason: d11 RC reserved (0) Jan 2 09:53:48 wlceventd: WLCEVENTD wlceventd_proc_event(430): eth6: ReAssoc 84:AD:8D:9B:B2:38, status: 0, reason: d11 RC reserved (0) Jan 2 09:56:19 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth6: Deauth_ind 84:AD:8D:9B:B2:38, status: 0, reason: Disassociated due to inactivity (4) Jan 2 09:56:19 wlceventd: WLCEVENTD wlceventd_proc_event(401): eth6: Disassoc 84:AD:8D:9B:B2:38, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Just curious, when your dns goes out, have you noticed cpu spikes on the status page? This happens to me about every 2-3 days.As of 1/1/20 my DNS keeps failing after some time on my AC86U. This happens on both 384.14 and 384.14_2, with DNS over TLS, using Cloudflare, Quad9, or NextDNS.
When I restart the dnsmasq service DNS works fine for a while, until it stops and I have to manually restart the service again.
How can I debug/fix this?
Will check the next time (frequency is much higher here: almost every hour?).Just curious, when your dns goes out, have you noticed cpu spikes on the status page? This happens to me about every 2-3 days.
Welcome To SNBForums
SNBForums is a community for anyone who wants to learn about or discuss the latest in wireless routers, network storage and the ins and outs of building and maintaining a small network.
If you'd like to post a question, simply register and have at it!
While you're at it, please check out SmallNetBuilder for product reviews and our famous Router Charts, Ranker and plenty more!