[Release] Asuswrt-Merlin 384.10 is now available

[fearz]

Ok so when I uninstalled diversion and removed the flash drive...CPU is back to normal..

 

[Butterfly Bones]

Ok so when I uninstalled diversion and removed the flash drive...CPU is back to normal..

I had this happen once. Do the command line install of Diversion again, and it will repair itself. See here for the command.
https://diversion.ch/diversion/installation.html

 

[galen2]

I uploaded a few test builds with the Quagga fix, please give them a try.

https://asuswrt.lostrealm.ca/test-builds

Also make sure to remove the suggested workaround script if you had created one.

Movistar IPTV working fine here with AC88U and the test build. Thank you.

 

[RMerlin]

Routes have returned and everything is working for the moment (TV channels, menus and VOD)
I'll will test throughly later but it looks good.

Working fine here with AC88U. Thank you.

Thanks for the confirmation.

 

[fearz]

I had this happen once. Do the command line install of Diversion again, and it will repair itself. See here for the command.
https://diversion.ch/diversion/installation.html

Kudos! So far so good...crossing fingers Thank you!

 

[rromeroa]

I uploaded a few test builds with the Quagga fix, please give them a try.

Movistar's IPTV service is working now in my AC68U. Thank you very much for the quickly resolution.

 

[lifeisfun]

Upgraded my 10 days old 3100 this morning, all worked fine for about 12 hours now wireles refuses to keep cliens connected, rebooted, still no joy, flashed again, still no difference.
Any ideas? Coincidence?

Just part of the log
Mar 28 18:44:04 dnsmasq-dhcp[301]: DHCPDISCOVER(br0) 60:01:94:96:b7:8a
Mar 28 18:44:04 dnsmasq-dhcp[301]: DHCPOFFER(br0) 192.168.1.123 60:01:94:96:b7:8a
Mar 28 18:44:05 WLCEVENTD: eth1: Assoc 4865:80:A1:6B
Mar 28 18:44:10 WLCEVENTD: eth1: Assoc B0:4E:26:1F:ECA
Mar 28 18:44:13 WLCEVENTD: eth1: Assoc 00:04:20:EA:B8:50
Mar 28 18:44:21 WLCEVENTD: eth1: Assoc B0:4E:26:1F:ECA
Mar 28 18:44:23 WLCEVENTD: eth1: Assoc 00:04:20:E7:EE:8F
Mar 28 18:44:29 WLCEVENTD: eth1: Assoc C4:7F:51:05:3E:89
Mar 28 18:44:30 dnsmasq-dhcp[301]: DHCPDISCOVER(br0) c4:7f:51:05:3e:89
Mar 28 18:44:30 dnsmasq-dhcp[301]: DHCPOFFER(br0) 192.168.1.120 c4:7f:51:05:3e:89
Mar 28 18:44:30 dnsmasq-dhcp[301]: DHCPREQUEST(br0) 192.168.1.120 c4:7f:51:05:3e:89
Mar 28 18:44:30 dnsmasq-dhcp[301]: DHCPACK(br0) 192.168.1.120 c4:7f:51:05:3e:89 MySmrtBlindsHUB
Mar 28 18:44:30 dnsmasq-dhcp[301]: DHCPINFORM(br0) 192.168.1.120 c4:7f:51:05:3e:89
Mar 28 18:44:30 dnsmasq-dhcp[301]: DHCPACK(br0) 192.168.1.120 c4:7f:51:05:3e:89 MySmrtBlindsHUB
Mar 28 18:44:30 dnsmasq-dhcp[301]: DHCPINFORM(br0) 192.168.1.120 c4:7f:51:05:3e:89
Mar 28 18:44:30 dnsmasq-dhcp[301]: DHCPACK(br0) 192.168.1.120 c4:7f:51:05:3e:89 MySmrtBlindsHUB
Mar 28 18:44:33 WLCEVENTD: eth1: Assoc B0:4E:26:1F:ECA
Mar 28 18:44:34 WLCEVENTD: eth1: Assoc B0:4E:26:19:59:53
Mar 28 18:44:42 WLCEVENTD: eth1: Assoc B0:4E:26:1F:ECA
Mar 28 18:44:44 WLCEVENTD: eth1: Assoc 4865:80:A1:6B
Mar 28 18:44:50 WLCEVENTD: eth1: Assoc B0:4E:26:1F:ECA
Mar 28 18:45:02 WLCEVENTD: eth1: Disassoc F4:F58:B2:FD:B0
Mar 28 18:45:03 WLCEVENTD: eth1: Assoc F0:03:8C:0B:22:99
Mar 28 18:45:03 WLCEVENTD: eth1: Assoc F0:03:8C:0B:22:99
Mar 28 18:45:03 dnsmasq-dhcp[301]: DHCPDISCOVER(br0) 60:01:94:96:b7:8a
Mar 28 18:45:03 dnsmasq-dhcp[301]: DHCPOFFER(br0) 192.168.1.123 60:01:94:96:b7:8a
Mar 28 18:45:07 dnsmasq-dhcp[301]: DHCPDISCOVER(br0) 48:d6:d5:80:a1:6b
Mar 28 18:45:07 dnsmasq-dhcp[301]: DHCPOFFER(br0) 192.168.1.170 48:d6:d5:80:a1:6b
Mar 28 18:45:07 WLCEVENTD: eth2: Assoc 8C:45:00:26:30:A6
Mar 28 18:45:08 WLCEVENTD: eth1: Disassoc F0:03:8C:0B:22:99
Mar 28 18:45:08 WLCEVENTD: eth1: Assoc B0:4E:26:19:59:53
Mar 28 18:45:09 WLCEVENTD: eth1: Assoc 00:04:20:EA:A9:37
Mar 28 18:45:17 WLCEVENTD: eth1: Assoc 00:04:20:E7:EE:8F
Mar 28 18:45:22 WLCEVENTD: eth1: Assoc 00:04:20:EA:B8:50
Mar 28 18:45:24 WLCEVENTD: eth1: Assoc 00:04:20:EA:A9:37
Mar 28 18:45:34 WLCEVENTD: eth1: Assoc 50:C7:BF:A6:39:A2
Mar 28 18:45:36 WLCEVENTD: eth1: Assoc E4:F0:42:26:82:49
Mar 28 18:45:37 WLCEVENTD: eth1: Assoc F4:F58:C1:23:F4
Mar 28 18:45:40 dnsmasq-dhcp[301]: DHCPDISCOVER(br0) 50:c7:bf:a6:39:a2
Mar 28 18:45:40 dnsmasq-dhcp[301]: DHCPOFFER(br0) 192.168.1.111 50:c7:bf:a6:39:a2
Mar 28 18:45:41 WLCEVENTD: eth2: Assoc 00:9E:C8:B4:ED:AB
Mar 28 18:45:41 dnsmasq-dhcp[301]: DHCPDISCOVER(br0) 00:9e:c8:b4:ed:ab
Mar 28 18:45:41 dnsmasq-dhcp[301]: DHCPOFFER(br0) 192.168.1.108 00:9e:c8:b4:ed:ab
Mar 28 18:45:41 dnsmasq-dhcp[301]: DHCPREQUEST(br0) 192.168.1.108 00:9e:c8:b4:ed:ab
Mar 28 18:45:41 dnsmasq-dhcp[301]: DHCPACK(br0) 192.168.1.108 00:9e:c8:b4:ed:ab MiBoxKitchen
Mar 28 18:45:41 dnsmasq-dhcp[301]: DHCPDISCOVER(br0) 50:c7:bf:a6:39:a2
Mar 28 18:45:41 dnsmasq-dhcp[301]: DHCPOFFER(br0) 192.168.1.111 50:c7:bf:a6:39:a2
Mar 28 18:45:42 WLCEVENTD: eth1: Assoc 00:04:20:E7:EE:8F
Mar 28 18:45:43 dnsmasq-dhcp[301]: DHCPDISCOVER(br0) 50:c7:bf:a6:39:a2
Mar 28 18:45:43 dnsmasq-dhcp[301]: DHCPOFFER(br0) 192.168.1.111 50:c7:bf:a6:39:a2
Mar 28 18:45:43 WLCEVENTD: eth2: Disassoc 8C:45:00:26:30:A6
Mar 28 18:45:44 dnsmasq-dhcp[301]: DHCPDISCOVER(br0) e4:f0:42:26:82:49
Mar 28 18:45:44 dnsmasq-dhcp[301]: DHCPOFFER(br0) 192.168.1.106 e4:f0:42:26:82:49
Mar 28 18:45:47 WLCEVENTD: eth1: Assoc 8C:45:00:26:30:A6
Mar 28 18:45:47 WLCEVENTD: eth1: Assoc 00:04:20:EA:B8:50
Mar 28 18:45:55 dnsmasq-dhcp[301]: DHCPDISCOVER(br0) e4:f0:42:26:82:49
Mar 28 18:45:55 dnsmasq-dhcp[301]: DHCPOFFER(br0) 192.168.1.106 e4:f0:42:26:82:49
Mar 28 18:45:55 dnsmasq-dhcp[301]: DHCPREQUEST(br0) 192.168.1.106 e4:f0:42:26:82:49
Mar 28 18:45:55 dnsmasq-dhcp[301]: DHCPACK(br0) 192.168.1.106 e4:f0:42:26:82:49 GH2
Mar 28 18:46:04 dnsmasq-dhcp[301]: DHCPDISCOVER(br0) 60:01:94:96:b7:8a
Mar 28 18:46:04 dnsmasq-dhcp[301]: DHCPOFFER(br0) 192.168.1.123 60:01:94:96:b7:8a
Mar 28 18:46:04 dnsmasq-dhcp[301]: DHCPREQUEST(br0) 192.168.1.123 60:01:94:96:b7:8a
Mar 28 18:46:04 dnsmasq-dhcp[301]: DHCPACK(br0) 192.168.1.123 60:01:94:96:b7:8a RGBlights1
Mar 28 18:46:04 WLCEVENTD: eth1: Assoc 00:04:20:EA:A9:37
Mar 28 18:46:05 WLCEVENTD: eth1: Assoc B0:4E:26:19:59:53
Mar 28 18:46:06 dnsmasq-dhcp[301]: DHCPREQUEST(br0) 192.168.1.123 60:01:94:96:b7:8a
Mar 28 18:46:06 dnsmasq-dhcp[301]: DHCPACK(br0) 192.168.1.123 60:01:94:96:b7:8a RGBlights1
Mar 28 18:46:07 WLCEVENTD: eth1: Assoc 00:04:20:E7:EE:8F
Mar 28 18:46:09 WLCEVENTD: eth1: Assoc F0:03:8C:0B:22:99
Mar 28 18:46:13 WLCEVENTD: eth1: Assoc F4:F58:B2:FD:B0
Mar 28 18:46:14 WLCEVENTD: eth2: Assoc 8C:45:00:26:30:A6
Mar 28 18:46:14 WLCEVENTD: eth1: Disassoc F0:03:8C:0B:22:99
Mar 28 18:46:18 WLCEVENTD: eth1: Disassoc 00:04:20:E7:EE:8F
Mar 28 18:46:20 WLCEVENTD: eth1: Disassoc E4:F0:42:26:82:49
Mar 28 18:46:20 WLCEVENTD: eth1: Disassoc 50:C7:BF:A6:39:A2
Mar 28 18:46:20 WLCEVENTD: eth1: Disassoc 4865:80:A1:6B
Mar 28 18:46:22 WLCEVENTD: eth1: Assoc 00:04:20:E7:EE:8F

 

[Xentrk]

Upgraded my 10 days old 3100 this morning, all worked fine for about 12 hours now wireles refuses to keep cliens connected, rebooted, still no joy, flashed again, still no difference.
Any ideas? Coincidence?

I replied to a similar post here:
https://www.snbforums.com/threads/r...-10-is-now-available.55742/page-7#post-475098

Please let us know if any of those suggestions work.

Edit: Just saw a post from @maxbraketorque.

Assoc/disassoc events are normal, but they are not usually reported in the log. ASUS introduced a bug in 45149 that caused these to be reported in the log. This has to be fixed by ASUS. These should have been present with 384.9 as well

 

[lifeisfun]

I replied to a similar post here:
https://www.snbforums.com/threads/r...-10-is-now-available.55742/page-7#post-475098

Please let us know if any of those suggestions work.

Thanks for reply!

First test

• MU-MIMO (some hardware revisions have non-functional/unreliable implementations)
• Airtime Fairness (causes connectivity issues for various devices, including wireless printers)
• Universal Beamforming (non-standard, might cause compatibility issues with some clients)

No difference

Will try other suggested help

 

[EmeraldDeer]

Thanks for reply!

First test

• MU-MIMO (some hardware revisions have non-functional/unreliable implementations)
• Airtime Fairness (causes connectivity issues for various devices, including wireless printers)
• Universal Beamforming (non-standard, might cause compatibility issues with some clients)

No difference

Will try other suggested help

If you run a netstat from the router, are there an unusual amount of connections from devices on your LAN which use multicast, possibly to miniupnpd?

 

[lifeisfun]

If you run a netstat from the router, are there an unusual amount of connections from devices on your LAN which use multicast, possibly to miniupnpd?

Active Internet connections (servers and established)

Not sure , but couldn't post the whole thing, it was too long
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:8481 0.0.0.0:* LISTEN 1239/asus_lighttpd
tcp 0 0 0.0.0.0:5473 0.0.0.0:* LISTEN 645/u2ec
tcp 0 0 0.0.0.0:18017 0.0.0.0:* LISTEN 256/wanduck
tcp 0 0 0.0.0.0:3394 0.0.0.0:* LISTEN 645/u2ec
tcp 0 0 192.168.1.1:515 0.0.0.0:* LISTEN 646/lpd
tcp 0 0 192.168.1.1:1990 0.0.0.0:* LISTEN 285/wps_monitor
tcp 0 0 0.0.0.0:8200 0.0.0.0:* LISTEN 2913/minidlna
tcp 0 0 127.0.0.1:139 0.0.0.0:* LISTEN 2751/smbd
tcp 0 0 192.168.1.1:139 0.0.0.0:* LISTEN 2751/smbd
tcp 0 0 192.168.1.1:9100 0.0.0.0:* LISTEN 646/lpd
tcp 0 0 0.0.0.0:7788 0.0.0.0:* LISTEN 418/cfg_server
tcp 0 0 127.0.0.1:80 0.0.0.0:* LISTEN 312/httpd
tcp 2 0 192.168.1.1:80 0.0.0.0:* LISTEN 312/httpd
tcp 0 0 0.0.0.0:8081 0.0.0.0:* LISTEN 1239/asus_lighttpd
tcp 0 0 0.0.0.0:21 0.0.0.0:* LISTEN 2754/vsftpd
tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN 302/dnsmasq
tcp 0 0 192.168.1.1:53 0.0.0.0:* LISTEN 302/dnsmasq
tcp 0 0 0.0.0.0:46806 0.0.0.0:* LISTEN 2760/miniupnpd
tcp 0 0 192.168.1.1:22 0.0.0.0:* LISTEN 271/dropbear
tcp 0 0 127.0.0.1:8443 0.0.0.0:* LISTEN 311/httpds
tcp 0 0 192.168.1.1:8443 0.0.0.0:* LISTEN 311/httpds
tcp 0 0 127.0.0.1:445 0.0.0.0:* LISTEN 2751/smbd
tcp 0 0 192.168.1.1:445 0.0.0.0:* LISTEN 2751/smbd
tcp 0 0 192.168.1.1:3838 0.0.0.0:* LISTEN 646/lpd
tcp 0 0 192.168.1.1:80 192.168.1.133:53719 TIME_WAIT -
tcp 0 0 192.168.1.1:80 192.168.1.133:53665 TIME_WAIT -
tcp 0 0 192.168.1.1:80 192.168.1.133:53736 TIME_WAIT -
tcp 0 0 192.168.1.1:80 192.168.1.133:53744 TIME_WAIT -
tcp 0 0 192.168.1.1:80 192.168.1.133:53701 TIME_WAIT -
tcp 509 0 192.168.1.1:80 192.168.1.133:53762 ESTABLISHED -
tcp 0 0 192.168.1.1:80 192.168.1.133:53729 TIME_WAIT -
tcp 0 0 170.52.82.76:53494 184.84.243.218:80 ESTABLISHED 2145/wred
tcp 0 0 192.168.1.1:80 192.168.1.133:53653 TIME_WAIT -
tcp 0 0 192.168.1.1:80 192.168.1.133:53645 TIME_WAIT -
tcp 0 0 192.168.1.1:80 192.168.1.133:53745 TIME_WAIT -
tcp 0 0 192.168.1.1:80 192.168.1.133:53691 TIME_WAIT -
tcp 0 0 192.168.1.1:80 192.168.1.133:53668 TIME_WAIT -
tcp 0 0 192.168.1.1:80 192.168.1.133:53643 TIME_WAIT -
tcp 0 0 192.168.1.1:80 192.168.1.133:53703 TIME_WAIT -
tcp 0 0 192.168.1.1:80 192.168.1.133:53698 TIME_WAIT -
tcp 0 0 192.168.1.1:80 192.168.1.133:53685 TIME_WAIT -
tcp 0 0 192.168.1.1:80 192.168.1.133:53751 TIME_WAIT -
tcp 0 0 192.168.1.1:80 192.168.1.133:53649 TIME_WAIT -
tcp 0 0 192.168.1.1:80 192.168.1.133:53726 TIME_WAIT -
tcp 0 0 192.168.1.1:80 192.168.1.133:53697 TIME_WAIT -
tcp 0 0 170.52.82.76:36360 184.84.243.193:80 ESTABLISHED 2145/wred
tcp 0 0 192.168.1.1:80 192.168.1.133:53727 TIME_WAIT -
tcp 0 0 170.52.82.76:53493 184.84.243.218:80 ESTABLISHED 2145/wred
tcp 0 0 192.168.1.1:80 192.168.1.133:53693 TIME_WAIT -
tcp 0 0 192.168.1.1:80 192.168.1.133:53669 TIME_WAIT -
tcp 0 0 192.168.1.1:80 192.168.1.133:53650 TIME_WAIT -
tcp 0 0 170.52.82.76:33543 184.84.243.194:80 ESTABLISHED 2145/wred
tcp 0 0 192.168.1.1:80 192.168.1.133:53714 TIME_WAIT -
tcp 0 0 192.168.1.1:80 192.168.1.133:53670 TIME_WAIT -
tcp 0 0 192.168.1.1:80 192.168.1.133:53696 TIME_WAIT -
tcp 0 0 192.168.1.1:80 192.168.1.133:53708 TIME_WAIT -
tcp 507 0 192.168.1.1:80 192.168.1.133:53759 ESTABLISHED -
tcp 0 0 192.168.1.1:80 192.168.1.133:53722 TIME_WAIT -
tcp 0 0 170.52.82.76:36364 184.84.243.193:80 ESTABLISHED 2145/wred
tcp 0 0 192.168.1.1:80 192.168.1.133:53652 TIME_WAIT -
tcp 0 0 192.168.1.1:80 192.168.1.133:53724 TIME_WAIT -
tcp 0 0 192.168.1.1:80 192.168.1.133:53739 TIME_WAIT -
tcp 0 0 192.168.1.1:80 192.168.1.133:53699 TIME_WAIT -
tcp 0 0 192.168.1.1:80 192.168.1.133:53749 TIME_WAIT -
tcp 0 0 192.168.1.1:80 192.168.1.133:53688 TIME_WAIT -
tcp 0 0 192.168.1.1:80 192.168.1.133:53656 TIME_WAIT -
tcp 0 0 192.168.1.1:80 192.168.1.133:53709 TIME_WAIT -
tcp 0 0 192.168.1.1:80 192.168.1.133:53674 TIME_WAIT -
tcp 0 0 192.168.1.1:80 192.168.1.133:53694 TIME_WAIT -
tcp 0 0 192.168.1.1:80 192.168.1.133:53655 TIME_WAIT -
tcp 0 0 192.168.1.1:80 192.168.1.133:53687 TIME_WAIT -
tcp 0 0 192.168.1.1:80 192.168.1.133:53746 TIME_WAIT -
tcp 0 0 192.168.1.1:80 192.168.1.133:53734 TIME_WAIT -
tcp 0 0 192.168.1.1:80 192.168.1.133:53644 TIME_WAIT -
tcp 0 0 192.168.1.1:80 192.168.1.133:53715 TIME_WAIT -
tcp 0 0 192.168.1.1:80 192.168.1.133:53662 TIME_WAIT -
tcp 0 0 192.168.1.1:80 192.168.1.133:53664 TIME_WAIT -
tcp 0 0 192.168.1.1:80 192.168.1.133:53750 TIME_WAIT -
tcp 505 0 192.168.1.1:80 192.168.1.133:53760 ESTABLISHED -
tcp 0 0 192.168.1.1:80 192.168.1.133:53676 TIME_WAIT -
tcp 0 0 192.168.1.1:80 192.168.1.133:53732 TIME_WAIT -
tcp 0 0 192.168.1.1:80 192.168.1.133:53742 TIME_WAIT -
tcp 0 0 192.168.1.1:80 192.168.1.133:53651 TIME_WAIT -
tcp 0 0 170.52.82.76:53495 184.84.243.218:80 ESTABLISHED 2145/wred
tcp 0 0 192.168.1.1:80 192.168.1.133:53661 TIME_WAIT -
tcp 0 0 170.52.82.76:33547 184.84.243.194:80 ESTABLISHED 2145/wred
tcp 0 0 192.168.1.1:80 192.168.1.133:53748 TIME_WAIT -
tcp 0 0 192.168.1.1:80 192.168.1.133:53740 TIME_WAIT -
tcp 0 0 192.168.1.1:80 192.168.1.133:53704 TIME_WAIT -
tcp 0 0 192.168.1.1:80 192.168.1.133:53673 TIME_WAIT -

 

[lifeisfun]

I replied to a similar post here:
https://www.snbforums.com/threads/r...-10-is-now-available.55742/page-7#post-475098

Please let us know if any of those suggestions work.

Edit: Just saw a post from @maxbraketorque.

Rolled back to 384.9 and now that has the same problem
Should I try to roll back even further or is that pointless?

 

[QuikSilver]

Rolled back to 384.9 and now that has the same problem
Should I try to roll back even further or is that pointless?

If you didn't have issue on previous firmware before you updated to 384.10 and now you have it on 384.9, I would think something with your config possibly.

 

[maxbraketorque]

Rolled back to 384.9 and now that has the same problem
Should I try to roll back even further or is that pointless?

The assoc/disassoc entries in the log do not necessarily point to connection issues. One of my neighbors has a wireless device that is constantly assessing all the wifi access points in the area. I see an assoc/disassoc entry in the router log ever few seconds as a result of this device. Some devices such a ipads and phones will disassoc during sleep. And when a device roams from one AP to the next that will also produce a disassoc/assoc event. Bottom line is that you need to look at the MAC address to determine what devices are producing the assoc/disassoc events and then determine if these are connectivity issues or normal events.

 

[Morac]

Rolled back to 384.9 and now that has the same problem
Should I try to roll back even further or is that pointless?

384.9 and 384.10 are based on the same ASUS code. You could try 384.8_2 as that’s based on older ASUS code.

That’s what I’m on now because of issues with 384.9. I plan to try out 384.10 this weekend.

 

[EmeraldDeer]

Active Internet connections (servers and established)

Not sure , but couldn't post the whole thing, it was too long
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:8481 0.0.0.0:* LISTEN 1239/asus_lighttpd
tcp 0 0 0.0.0.0:5473 0.0.0.0:* LISTEN 645/u2ec
tcp 0 0 0.0.0.0:18017 0.0.0.0:* LISTEN 256/wanduck
tcp 0 0 0.0.0.0:3394 0.0.0.0:* LISTEN 645/u2ec
tcp 0 0 192.168.1.1:515 0.0.0.0:* LISTEN 646/lpd
tcp 0 0 192.168.1.1:1990 0.0.0.0:* LISTEN 285/wps_monitor
tcp 0 0 0.0.0.0:8200 0.0.0.0:* LISTEN 2913/minidlna
tcp 0 0 127.0.0.1:139 0.0.0.0:* LISTEN 2751/smbd
tcp 0 0 192.168.1.1:139 0.0.0.0:* LISTEN 2751/smbd
tcp 0 0 192.168.1.1:9100 0.0.0.0:* LISTEN 646/lpd
tcp 0 0 0.0.0.0:7788 0.0.0.0:* LISTEN 418/cfg_server
tcp 0 0 127.0.0.1:80 0.0.0.0:* LISTEN 312/httpd
tcp 2 0 192.168.1.1:80 0.0.0.0:* LISTEN 312/httpd
tcp 0 0 0.0.0.0:8081 0.0.0.0:* LISTEN 1239/asus_lighttpd
tcp 0 0 0.0.0.0:21 0.0.0.0:* LISTEN 2754/vsftpd
tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN 302/dnsmasq
tcp 0 0 192.168.1.1:53 0.0.0.0:* LISTEN 302/dnsmasq
tcp 0 0 0.0.0.0:46806 0.0.0.0:* LISTEN 2760/miniupnpd

Even though there is no evidence, perhaps it would be worth enabling IGMP proxy and optionally IGMP snooping in case there is a multicast storm because nothing is responding to muliticast devices.
On my router IGMP Proxy is under LAN > IPTV
IGMP snooping is under Wireless > Professional

 

[lifeisfun]

The assoc/disassoc entries in the log do not necessarily point to connection issues. One of my neighbors has a wireless device that is constantly assessing all the wifi access points in the area. I see an assoc/disassoc entry in the router log ever few seconds as a result of this device. Some devices such a ipads and phones will disassoc during sleep. And when a device roams from one AP to the next that will also produce a disassoc/assoc event. Bottom line is that you need to look at the MAC address to determine what devices are producing the assoc/disassoc events and then determine if these are connectivity issues or normal events.

They all do that, no wireless client stays connected.
Tried to default the router and problem persists.
Could I have hardware problem?

 

[lifeisfun]

384.9 and 384.10 are based on the same ASUS code. You could try 384.8_2 as that’s based on older ASUS code.

That’s what I’m on now because of issues with 384.9. I plan to try out 384.10 this weekend.

I had 384.9 running flawless for 10 days, only today after updating to .10 12 hours after the update this mess started

 

[maxbraketorque]

I had 384.9 running flawless for 10 days, only today after updating to .10 12 hours after the update this mess started

But are your devices actually experiencing measurable connection issues?

 

[Vexira]

Hi, does anyone know if there is a problem with Chinese mobile phones and American routers Asus in WIFI connections? I use a OnePlus 6 and my Ac86u (US) sometimes hangs, does not surf, it takes to get back even with the last update. I read that other cell phones such as google pixel 2 had problems causing the router to reboot. If I use an AC66 with firmware tomato, latest version, everything works fine. Even with an older wireless internet driver, and this problem just happen to my OP6.

Is your android up to date my Oppo find X works fine but it's an Australian model same as my 88u try reflash with an international rom.if yours is from China