What's new

[Release] Asuswrt-Merlin 384.9 is now available

  • 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!

I wonder why worry about associations and disassociations? I have that as well but the router and all clients work beautifully....

I am aware that it is a mania, but in the registry I’m only interested in seeing the important info. Believe me, in two days I had a lot of entries with associations.

The best thing would be to be able to choose whether to activate or deactivate this log but I don’t know if it’s in Merlin’s hands.
 
I'm losing my internet connection several times a day.
I give the reboot command on stubby and the link goes online again.
Would the problem be in Stubby or Asuswrt?

Code:
Feb  8 07:11:05 WLCEVENTD: wl0.1: Disassoc 68:C6:3A:A3:45:1A
Feb  8 07:11:07 WLCEVENTD: wl0.1: Assoc 68:C6:3A:A3:45:1A
Feb  8 07:11:07 dnsmasq-dhcp[767]: DHCPDISCOVER(br0) 68:c6:3a:a3:45:1a
Feb  8 07:11:07 dnsmasq-dhcp[767]: DHCPOFFER(br0) 192.168.10.34 68:c6:3a:a3:45:1a
Feb  8 07:11:07 dnsmasq-dhcp[767]: DHCPREQUEST(br0) 192.168.10.34 68:c6:3a:a3:45:1a
Feb  8 07:11:07 dnsmasq-dhcp[767]: DHCPACK(br0) 192.168.10.34 68:c6:3a:a3:45:1a ESP_A3451A
Feb  8 07:11:18 dnsmasq-dhcp[767]: DHCPREQUEST(br0) 192.168.10.33 84:8e:0c:bf:e9:e4
Feb  8 07:11:18 dnsmasq-dhcp[767]: DHCPACK(br0) 192.168.10.33 84:8e:0c:bf:e9:e4 iPadMini
Feb  8 07:28:08 dnsmasq-dhcp[767]: DHCPREQUEST(br0) 192.168.10.9 30:9c:23:df:4e:4b
Feb  8 07:28:08 dnsmasq-dhcp[767]: DHCPACK(br0) 192.168.10.9 30:9c:23:df:4e:4b Ryzen
Feb  8 07:41:54 WLCEVENTD: eth5: Assoc 84:8E:0C:BF:E9:E4
Feb  8 07:41:54 WLCEVENTD: eth6: Disassoc 84:8E:0C:BF:E9:E4
Feb  8 07:41:54 WLCEVENTD: eth6: Disassoc 84:8E:0C:BF:E9:E4
Feb  8 07:41:55 dnsmasq-dhcp[767]: DHCPDISCOVER(br0) 84:8e:0c:bf:e9:e4
Feb  8 07:41:55 dnsmasq-dhcp[767]: DHCPOFFER(br0) 192.168.10.33 84:8e:0c:bf:e9:e4
Feb  8 07:41:56 dnsmasq-dhcp[767]: DHCPREQUEST(br0) 192.168.10.33 84:8e:0c:bf:e9:e4
Feb  8 07:41:56 dnsmasq-dhcp[767]: DHCPACK(br0) 192.168.10.33 84:8e:0c:bf:e9:e4 iPadMini
Feb  8 07:49:18 dropbear[9550]: Child connection from 192.168.10.9:63058
Feb  8 07:49:18 dropbear[9550]: Password auth succeeded for 'admin' from 192.168.10.9:63058
Feb  8 06:49:34 S61stubby: restart Stubby DNS over TLS /opt/etc/init.d/S61stubby
Feb  8 06:49:35 admin: Started stubby from .
 
I am aware that it is a mania, but in the registry I’m only interested in seeing the important info. Believe me, in two days I had a lot of entries with associations.

The best thing would be to be able to choose whether to activate or deactivate this log but I don’t know if it’s in Merlin’s hands.
Mania? Associations are normal and expected. If clients associate and then disassociate in a few seconds (or less), there is a problem. You should only see such messages if the client is moving into and out of range of the access point or being turned on/off. Logging exists to help troubleshoot problems.
 
I am aware that it is a mania, but in the registry I’m only interested in seeing the important info. Believe me, in two days I had a lot of entries with associations.

The best thing would be to be able to choose whether to activate or deactivate this log but I don’t know if it’s in Merlin’s hands.
Add to post-mount:
Code:
cru a cleanup "*/10 * * * * /bin/sed -i '/WLCEVENTD:/d' /tmp/syslog.log #remove assos/disassos messages "
and those messages will be wiped every 10 minutes. Or install syslog-ng and learn how to use it.
 
STILL THINK asus is better at supporting the hardware than other router manufacturers , not perfect , but better , and with Merlin FW to catch and patch security flaws ,I'm sticking with my 3200's . so far 6 days and nothing unusual in the logs , connection solid as can be with 384.9 R
 
I'm losing my internet connection several times a day.
I give the reboot command on stubby and the link goes online again.
Would the problem be in Stubby or Asuswrt?

Could be the same or similar problem I had with my Sony TV. It would periodically complain the Internet or LAN was down and told me to check my router. Rebooting the TV would resolve the issue for awhile, but it would come back. I downgraded back to 384.8_2 and the problem went away.
 
Hey folks - I apologize but I can't find the answer.
I cannot seem to dirty upgrade my two 66U_B1 (68U firmware) from .8_2 to .9.
Is this a known issue?
My AC5300 took some nudging (a couple tries) but worked.
No dice on the 66U_B1/68U
 
For those that want to see your network map accurately try an app like Fing. It works pretty well.

Thanks Merlin.

I'm really impressed with the selective routing through the VPN. I spent a crazy amount of time getting it to work on my old PFsense box.
 
Dirty upgraded my AC86U from 384.8_2 to 384.9.

This is the first time I see both Runner and Flow Cache enabled in HW acceleration. For all previous version I had not been able to make Runner enabled and stay in its state. Now it stays enabled for hours. :):):)

So far no unusual log (finger crossed). When a WiFi device connected, there is Assoc log entry, and when the WiFi device disconnected, there is Disassoc entry. Which is normal and useful. Security wise, can make use of this log to track for WiFi stealing too. ;) I think it only trouble you if your router is in public place and you are providing WiFi for your guests, then it will be too much entries in the log.

WiFi log is showing more information. IPv6 log is cleaner than before.

Thanks Merlin, Asus and all contributors.
 
Dirty upgraded my AC86U from 384.8_2 to 384.9.

This is the first time I see both Runner and Flow Cache enabled in HW acceleration. For all previous version I had not been able to make Runner enabled and stay in its state. Now it stays enabled for hours. :):):)

With which settings (QOS, TrendMicro etc.) does it remain activated?

:)
 
With which settings (QOS, TrendMicro etc.) does it remain activated?

:)


As it is dirty upgrade, it is the same setting as before. Nothing changed. I just disconnected USB drive, apply firmware upgrade, after reboot switch off the router, connect back the USB drive, and switch it on.

Current settings:
QOS Apps analysis: on
Enable QOS: off
Classification is working
Web history: off
AiProtection: everything on
Parental controls: off

LAN-IPTV: set
Port forwarding: set for 2 ports
 
If you encounter frequent assoc and disassoc with the same WiFi device, perhaps you need to fine tune your Smart Connect Rule setting, or just disable Smart Connect.

Without the log does not mean your device didn't behave this way in previous firmware, just that you are unnoticed. With the log, it helps you to fine tune your WiFi connection to be more stable.

Some smartphone has the feature of switching between WiFi and mobile data, based on the smartphone's perception of which one is better. When switched away from WiFi, it will consume your mobile data quota.

Some smartphone has the feature of switching off WiFi when it is sleeping, and switch back on when screen is on.

The log is very useful and is a good feature. It tells you want is happening.

One thing I have not tried yet, but maybe those who doesn't want to see too much log entries can try: set default message log level to "warning" or higher, and log only messages more urgent than "notice".
 
Apologies if this has already been covered - I've read the entire thread but may have missed something, and haven't been up to date with the rest of the forum for a couple of weeks.

I flashed 384.9 and dnsmasq wouldn't start up properly. I tracked it down to having a "dhcp-script=" entry in my /jffs/configs/dnsmasq.conf.add file. (This pointed to a script that emailed me when a new device joins my guest wifi, which I based off https://www.snbforums.com/threads/identify-guest-network-clients.37355/#post-306755.)

It seems that there is now already a "dhcp-script=/sbin/dhcpc_lease" entry in the default /etc/dnsmasq.conf, so by adding my own "dhcp-script" line to dnsmasq.conf.add I was creating a duplicate command when the .add file was merged in, and dnsmasq wouldn't start up. I don't think dhcp-script was present in /etc/dnsmasq.conf in previous releases but I could easily be wrong, will try to investigate more later.

All resolved now, though I'll have to find another way of getting those email notifications. If anyone has any insights I'd be glad to hear them, but for now I'm just posting this in case it's useful to anyone else.

PS. Almost forgot to say thanks for the update. :)
 
Last edited:
I'm losing my internet connection several times a day.
I give the reboot command on stubby and the link goes online again.
Would the problem be in Stubby or Asuswrt?

Code:
Feb  8 07:11:05 WLCEVENTD: wl0.1: Disassoc 68:C6:3A:A3:45:1A
Feb  8 07:11:07 WLCEVENTD: wl0.1: Assoc 68:C6:3A:A3:45:1A
Feb  8 07:11:07 dnsmasq-dhcp[767]: DHCPDISCOVER(br0) 68:c6:3a:a3:45:1a
Feb  8 07:11:07 dnsmasq-dhcp[767]: DHCPOFFER(br0) 192.168.10.34 68:c6:3a:a3:45:1a
Feb  8 07:11:07 dnsmasq-dhcp[767]: DHCPREQUEST(br0) 192.168.10.34 68:c6:3a:a3:45:1a
Feb  8 07:11:07 dnsmasq-dhcp[767]: DHCPACK(br0) 192.168.10.34 68:c6:3a:a3:45:1a ESP_A3451A
Feb  8 07:11:18 dnsmasq-dhcp[767]: DHCPREQUEST(br0) 192.168.10.33 84:8e:0c:bf:e9:e4
Feb  8 07:11:18 dnsmasq-dhcp[767]: DHCPACK(br0) 192.168.10.33 84:8e:0c:bf:e9:e4 iPadMini
Feb  8 07:28:08 dnsmasq-dhcp[767]: DHCPREQUEST(br0) 192.168.10.9 30:9c:23:df:4e:4b
Feb  8 07:28:08 dnsmasq-dhcp[767]: DHCPACK(br0) 192.168.10.9 30:9c:23:df:4e:4b Ryzen
Feb  8 07:41:54 WLCEVENTD: eth5: Assoc 84:8E:0C:BF:E9:E4
Feb  8 07:41:54 WLCEVENTD: eth6: Disassoc 84:8E:0C:BF:E9:E4
Feb  8 07:41:54 WLCEVENTD: eth6: Disassoc 84:8E:0C:BF:E9:E4
Feb  8 07:41:55 dnsmasq-dhcp[767]: DHCPDISCOVER(br0) 84:8e:0c:bf:e9:e4
Feb  8 07:41:55 dnsmasq-dhcp[767]: DHCPOFFER(br0) 192.168.10.33 84:8e:0c:bf:e9:e4
Feb  8 07:41:56 dnsmasq-dhcp[767]: DHCPREQUEST(br0) 192.168.10.33 84:8e:0c:bf:e9:e4
Feb  8 07:41:56 dnsmasq-dhcp[767]: DHCPACK(br0) 192.168.10.33 84:8e:0c:bf:e9:e4 iPadMini
Feb  8 07:49:18 dropbear[9550]: Child connection from 192.168.10.9:63058
Feb  8 07:49:18 dropbear[9550]: Password auth succeeded for 'admin' from 192.168.10.9:63058
Feb  8 06:49:34 S61stubby: restart Stubby DNS over TLS /opt/etc/init.d/S61stubby
Feb  8 06:49:35 admin: Started stubby from .
Disable Network Monitoring.

Sent from my SM-T380 using Tapatalk
 
Having this issue with my 3100 as well. I will try another channel to see if it works longer than a day or two. My 5GHz will not connect at all since upgrade. I factory reset then used the restore tool.

Sent from my SM-N960U using Tapatalk
 
Last edited:
Hey folks - I apologize but I can't find the answer.
I cannot seem to dirty upgrade my two 66U_B1 (68U firmware) from .8_2 to .9.
Is this a known issue?
My AC5300 took some nudging (a couple tries) but worked.
No dice on the 66U_B1/68U

Was able to dirty flash my 66U_B1 from .8_2 to .9 without incident. Been up for over 6 days.
 
Had a lot of dropouts with 384.8.0 and 2. Had to restart the router every now and then. 384.9 runs rock solid. Running 2 86U's. 1 as a Router and 1 as a media-bridge. Also a Netgear EX8000 as media-bridge.
Accessing the 2 media-bridges often fail via Firefox and Edge after updating to 384.9. Any suggestions?
 
Last edited:
7 days uptime and WiFi is rock solid. I have four iOS devices, two TVs and a laptop on the network. Thank you, Eric!
 

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