AC-68U 386.2_4 wifi dropping

tbarbone

New Around Here
Hi Everyone,

This is my first time using customer firmware for routers and the merlin firmware seems great. I have been having issues how ever with 386.2_4. I keep having consistent wifi drops and have to disconnect and reconnect to get things going again. This is mainly happening on my Iphone 12, but I have noticed it on my windows laptop occasionally and I have even noticed some slow downs on my samsung smart tv that is plugged in. Though the TV has not disconnected as far as I know. I will post the wifi and professional screenshots. The other factor I have involved in my set up is my raspberry pi. I am using portainer and PI hole to block ads on my network. I am using the pi hole as the LAN DNS. The WAN DNS is 1.1.1.1. I have removed the back up DNS's for both LAN and WAN to avoid DNS leaks letting in Ads. I should also state the Iphone I am noticing most of the issues with is connected to the 5ghz network.
 

Attachments

  • Professional -2.4ghz.PNG
    Professional -2.4ghz.PNG
    400.5 KB · Views: 125
  • Professional -5ghz.PNG
    Professional -5ghz.PNG
    396.7 KB · Views: 129
  • wireless.PNG
    wireless.PNG
    425.2 KB · Views: 121

Wallace_n_Gromit

Senior Member
Hi Everyone,

This is my first time using [custom] firmware for routers and the merlin firmware seems great. I have been having issues [however] with 386.2_4. I keep having consistent wifi drops and have to disconnect and reconnect to get things going again. ~

What router are you using?

Did you have issues with drops prior to installing AsusMerlin firmware? I'm guessing you were using stock Asus firmware.

Try going back to the prior firmware (that worked for you) and see if that prior stock Asus firmware still works without the periodic wifi drops, or are you still experiencing wifi drops.

Merlin does have a firmware version in alpha development that does provide some security updates (and perhaps other known issues) from Asus for wifi.
 
Last edited:

tbarbone

New Around Here
Hi,

I am using the asus AC-68U.

I was using stock previously and I was not having any wifi drop issues. I will have to revert later today to test.
 

creatine

Regular Contributor
On 1st look, you have the control channel set to "auto". Try setting it to a fixed channel. Also, try disabling beamforming.
 

Wallace_n_Gromit

Senior Member
On 1st look, you have the control channel set to "auto". Try setting it to a fixed channel. Also, try disabling beamforming.
Also some have suggested that the 2.4GHz [Channel bandwidth] be set to 20MHz, and the 5GHz [Channel bandwidth] be set to 80MHz.
 

Zastoff

Very Senior Member
Hi,

I am using the asus AC-68U.

I was using stock previously and I was not having any wifi drop issues. I will have to revert later today to test.
Did you do a factory reset after flashing Merlin firmware on your router?
 

Wallace_n_Gromit

Senior Member
Did you do a factory reset after flashing Merlin firmware on your router?
*sigh* Of course, that was exactly the first thing the OP should have done, then repopulate his settings (that he should have recorded/noted).

>>I need to give myself a mental note about remembering how important a [Factory default--restore--with the "Initialize all the settings..." checkbox checked] is to the transition from stock to Merlin.

>>>but I'm getting so old my mental notes get misplaced easily :D
 
Last edited:

tbarbone

New Around Here
Hi,

No I did not do a factory reset after the flash. I did not realise that was a best practice.
 

tbarbone

New Around Here
I copied the connection settings from this post,


I don't have a mesh network, but so far it seems to have resolved the dropping.
 

Wallace_n_Gromit

Senior Member
I copied the connection settings from this post,


I don't have a mesh network, but so far it seems to have resolved the dropping.
Note that the very next post after the post you used to copy the connection settings that seem to work for you is by @L&LD.

He has made it his specialty to offer his documented best practices for all sorts of matters Asus routers and Asus/Merlin firmware. You can get informative links from his signature line.
 
Last edited:

gattaca

Senior Member
Since upgrading to 386.2_4 (from 384.19) and doing a full factory reset both software / hardware resets and greenfield setup of all values hand-copied from the earlier setup! ;) I've had non-stop issues with one IOT device failing to connect and stay connected properly on 2.4GHz (it only uses 2.4GHz). I have the channels locked in place etc... just like I had on 384.19.

This is been frustrating as its been rock solid on 384.19 for months! I've tried this setup (386.2_4) on both a RT-AC86U and RT-AC68U with the same results. :(

Each time the IOT device connects, it immediately disconnects. Yeah it a PITA IOT device but one I use daily.

Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Jun 4 07:16:12 wlceventd: wlceventd_proc_event(527): eth5: Auth 70:MAC...., status: Successful (0), rssi:0
 

jacbao

New Around Here
Since upgrading to 386.2_4 (from 384.19) and doing a full factory reset both software / hardware resets and greenfield setup of all values hand-copied from the earlier setup! ;) I've had non-stop issues with one IOT device failing to connect and stay connected properly on 2.4GHz (it only uses 2.4GHz). I have the channels locked in place etc... just like I had on 384.19.

This is been frustrating as its been rock solid on 384.19 for months! I've tried this setup (386.2_4) on both a RT-AC86U and RT-AC68U with the same results. :(

Each time the IOT device connects, it immediately disconnects. Yeah it a PITA IOT device but one I use daily.

Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Jun 4 07:16:12 wlceventd: wlceventd_proc_event(527): eth5: Auth 70:MAC...., status: Successful (0), rssi:0

I have same issue. upgrade from 384.19 to 386.2. there are 20+ IOT devices on my 2.4G network, 10 of 2x IOT device keep on/offline and finally stack.
 

gattaca

Senior Member
I've mined around on this issue... and everything I've attempted thusfar has failed to enable these IOT devices to reliably connect. Since I donated my old router to my family, I'm in the process of finding an older spare to install 384.19 on and test as a WAP / Router. Will be a week or two... will update then. I'm surprised more people have not been reporting this issue. Thanks.
 

orcan

New Around Here
I have same issue. upgrade from 384.19 to 386.2. there are 20+ IOT devices on my 2.4G network, 10 of 2x IOT device keep on/offline and finally stack.

I have a similar issue, but have been able to find a workaround, which does help, but I am unable to explain why.

To begin with I always had issues with connecting IoT devices even when running 384.19.
I am currently on 386.2_6 for my AiMesh Router: RT-AC86U, Nodes: RT-AC86U, RT-AC68U.

I have been able to stabilize my IoT devices (2.4G) as it appears the routers dislike new devices.
Older devices - on the network for several months - connect immediately even after reboot or power outage.
When adding a new device it behaves like described above incl the following log msgs: on/off loop, then stall:

Jun 21 18:55:33 dnsmasq-dhcp[2376]: DHCPDISCOVER(br0) xx:xx:xx:e5:6b:af
Jun 21 18:55:33 dnsmasq-dhcp[2376]: DHCPOFFER(br0) xxx.xxx.xxx.233 xx:xx:xx:e5:6b:af
Jun 21 18:55:48 wlceventd: wlceventd_proc_event(491): eth5: Deauth_ind xx:xx:xx:E5:6B:AF, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3), rssi:0
Jun 21 18:55:48 wlceventd: wlceventd_proc_event(508): eth5: Disassoc xx:xx:xx:E5:6B:AF, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Jun 21 18:55:48 wlceventd: wlceventd_proc_event(527): eth5: Auth xx:xx:xx:E5:6B:AF, status: Successful (0), rssi:0
Jun 21 18:55:48 wlceventd: wlceventd_proc_event(556): eth5: Assoc xx:xx:xx:E5:6B:AF, status: Successful (0), rssi:0
Jun 21 18:55:48 dnsmasq-dhcp[2376]: DHCPDISCOVER(br0) xx:xx:xx:e5:6b:af
Jun 21 18:55:48 dnsmasq-dhcp[2376]: DHCPOFFER(br0) xxx.xxx.xxx.233 xx:xx:xx:e5:6b:af

However, rebooting the router appears to help the device onto the network. And if that still fails, a factory reset of the router incl reloading config
usually gets the job done.
This even happened with a device I reactivated after it has been sitting in the drawer for the last 6 months.
It had been on the network for over a year prior deactivation but now needed the "extra help".
 
Last edited:

jacbao

New Around Here
I have a similar issue, but have been able to find a workaround, which does help, but I am unable to explain why.

To begin with I always had issues with connecting IoT devices even when running 384.19.
I am currently on 386.2_6 for my AiMesh Router: RT-AC86U, Nodes: RT-AC86U, RT-AC68U.

I have been able to stabilize my IoT devices (2.4G) as it appears the routers dislike new devices.
Older devices - on the network for several months - connect immediately even after reboot or power outage.
When adding a new device it behaves like described above incl the following log msgs: on/off loop, then stall:

Jun 21 18:55:33 dnsmasq-dhcp[2376]: DHCPDISCOVER(br0) xx:xx:xx:e5:6b:af
Jun 21 18:55:33 dnsmasq-dhcp[2376]: DHCPOFFER(br0) xxx.xxx.xxx.233 xx:xx:xx:e5:6b:af
Jun 21 18:55:48 wlceventd: wlceventd_proc_event(491): eth5: Deauth_ind xx:xx:xx:E5:6B:AF, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3), rssi:0
Jun 21 18:55:48 wlceventd: wlceventd_proc_event(508): eth5: Disassoc xx:xx:xx:E5:6B:AF, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Jun 21 18:55:48 wlceventd: wlceventd_proc_event(527): eth5: Auth xx:xx:xx:E5:6B:AF, status: Successful (0), rssi:0
Jun 21 18:55:48 wlceventd: wlceventd_proc_event(556): eth5: Assoc xx:xx:xx:E5:6B:AF, status: Successful (0), rssi:0
Jun 21 18:55:48 dnsmasq-dhcp[2376]: DHCPDISCOVER(br0) xx:xx:xx:e5:6b:af
Jun 21 18:55:48 dnsmasq-dhcp[2376]: DHCPOFFER(br0) xxx.xxx.xxx.233 xx:xx:xx:e5:6b:af

However, rebooting the router appears to help the device onto the network. And if that still fails, a factory reset of the router incl reloading config
usually gets the job done.
This even happened with a device I reactivated after it has been sitting in the drawer for the last 6 months.
It had been on the network for over a year prior deactivation but now needed the "extra help".
Orcan

thanks for the sharing.
your workaround is factory reset with reloading config? am I right?
and if any new/ re-activated device join, issue may triggered again?
 

orcan

New Around Here
Orcan

thanks for the sharing.
your workaround is factory reset with reloading config? am I right?
and if any new/ re-activated device join, issue may triggered again?
In general you are correct, but I usually try a simple reboot first while the IoT device is trying to connect.
Most of the time after the reboot the device gets an IP address by DHCP and connects to the WLAN.
Factory reset/reload config is an escalation step in case simple reboot does not help.
And yes, it will most likely happen again with other new devices. The frustrating thing is that the behaviour is
unpredictable, at least at my current level of understanding.
I am assuming it has sth to do with data structures in RAM and potentially even NVRAM,
 

Morris

Very Senior Member
To me the configuration problems are glaring, particular one.

Multiple issues in 2.5 Ghz Professional settings

Change roaming assistant to -70dB
Enable Bluetooth Coexistence
Disable Airtime Fairness
Disable both types of beamforming

The roaming assistant setting of -55db is requires way too strong a signal before dropping the client. This is the primary cause of your issues



On the 5 Ghz Professional Settings

Disable Universal Beam Forming
 

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