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!

First post ( and the release notes ) :
Thanks AndreiV. Yes I had read the change notes ;-) Question really is whether networkmap was fundamentally broken in all cases or just more sensitive to malformed hostnames which has been a known issue for a while. Sounds like RMerlin is implying “fundamentally broken” then :-(. Guess I’ll ditch my investigations and simply regress for now. Thanks for saving me some time.
 
AiProtection has never actually logged anything in the router GUI, even when it blocks something... nor does it send email (yes I supplied the gmail app password as credentials), and there's nothing to indicate a failed attempt to send email when the attempts to known bad sites get blocked by AiProtection.

Maybe it's something about the AC68U that's different from other hardware, or something else going on, but...

Hmm... AiProtection works fine for me. I cleared the Malicious Sites Blocking and IPS hit count to 0 after the upgrade. Infected Device Prevention and Blocking has always been 0 all the while.

Let me recall... at the first 2 hours, the Malicious Sites Blocking and IPS hit count remain at 0 although I purposely went and visit some torrent download sites which used to produce hits.
Running "ps" in ssh terminal can see process "dcd -i 3600 -p 43200 -b -d /tmp/bwdpi/" is up and running.

Then I saw hit counts in Malicious Sites Blocking and IPS shown in Asus Router app when I accessed the router using the app. When I access using web browser again, the hit counts also shown there now.

Maybe the Asus Router app has triggered something, or maybe just coincident. But AiProtection is working fine now, including IPS hit counts.
 
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.
Take a backup of your configuration just in case Murhpy shows up and disables Runner.
 
Thanks. It looks like there's a difference in our implementations, though. It looks like you're appending to dnsmasq.conf, which presumably means you don't already have a "dhcp-script=" line in it. My dnsmasq.conf already contains the line "dhcp-script=/sbin/dhcp_lease" so I'm using the post-conf to replace that with a call to my custom script, then calling the original "/sbin/dhcp_lease" at the end of my custom script. Possibly a difference between the two models of router?
Now that I accept that Asus inconsistently added dhcp_lease to the range of models, what you and Merlin are saying now makes complete sense. :)
So in that case, I would do the following, but I cannot test it.
Code:
# cat /jffs/scripts/dnsmasq.postconf
#!/bin/sh
CONFIG=$1
source /usr/sbin/helper.sh
pc_delete "no-negcache" $CONFIG
pc_append "neg-ttl=3600" $CONFIG
pc_replace "dhcp-script=/sbin/dhcp_lease" "dhcp-script=/jffs/scripts/log-dhcp.sh" $CONFIG
#
. /opt/share/diversion/file/post-conf.div # Added by Diversion

# cat /jffs/scripts/log-dhcp.sh
#!/bin/sh
myscriptname=`/usr/bin/basename $0`
/usr/bin/logger -t ${myscriptname} -p local6.info "Action $1, MAC $2, IP_address $3, Hostname $4"
/sbin/dhcp_lease "$@"
 
Now that I accept that Asus inconsistently added dhcp_lease to the range of models, what you and Merlin are saying now makes complete sense. :)
So in that case, I would do the following, but I cannot test it.
:D

Thanks, I used the same syntax (using "$@") after @Dabombber's post and it seems to be working fine. Not really sure what dhcp_lease is actually doing, so can't really tell whether it's still working as intended, but I see no reason to doubt that it is. :cool:
 
As mentioned many times above, my AC86U also goes through cycles of association, dissociation and reassociation of every wireless client after upgrade to 384.9. Problem does go away after rolling back to 384.8.2.
System log was filled with these WLCEVENTD events and that itself I don't really care. However, these wireless clients association and dissociation events does translate to disconnection and reset of smart devices and worst of all, anonying disruption of videos playing on Plex rhythmically every ten minutes. I've checked, roaming assist is turned off, smart connect is turned off, network monitoring is unchecked, QoS off, network traffic analyzer off and AI protection off. I hate to be a drag, and I believe multiple AC86U users have also reported, something is wrong with the 384.9 firmware for AC86U.
 
As mentioned many times above, my AC86U also go through cycles of associate, dissociate and reassociate of every wireless client after upgrade to 384.9. Problem goes away after rolling back to 384.8.2.
System log was filled with these WLCEVENTD events. That itself I don't really care. However, these wireless clients association and dissociation events cause disconnection and reset of smart devices and worst of all, anonying disruption of videos playing on Plex rhythmically every ten minutes. I've checked, roaming assist is turned off, smart connect is turned off, network monitoring is unchecked, QoS off, network traffic analyzer off and AI protection off. Hate to be a drag and I believe multiple AC86U users have reported, something is setting with the 384.9 firmware for AC86U.
My AC86U on 384.9 is absolutely fine...
 
384.9 has been running great on my AC86U and AC3200. I tested yesterday switching my AC68P Media Bridge from DD-WRT to 384.9 after performing a firmware recovery; however, the DHCP issue still exists where clients cannot obtain the DHCP address although the router is offering.
Is this DHCP issue related to the one discussed in this thread:
https://www.snbforums.com/threads/rt-ac68u-in-media-bridge-mode-responding-to-dhcp-requests.48259/
and this thread:
https://www.snbforums.com/threads/rt-ac68p-in-media-bridge-mode-dhcp-dnsmasq-problems.49576/?
This is a longstanding ASUS issue that I'm not hopeful will be addressed ...
Should I take this to mean this issue exists with Asus Official FW as well?
 
Last edited:
Me too on an AC87U. 35 clients in 384.7_2 and 11 in 384.9. All clients are connected but most that appear are being erroneously reported as wired rather than WiFi. I’m suspicious that the new firmware (the ASUS binary blob bit and networkmap specifically) may be more sensitive to weird hostnames. I have one device (a Surepet catflap) where the host name is “*” which is a likely target. I’m going to try turning all clients off and gradually reintroducing. However, before I start, immediately after the factory reset and nvram_restore/jffs_restore, I see two new clients in the list that weren’t there before. One called Asus with MAC of the 5G WiFi adapter and a 169.254 address and the other called FF:FF:FF:FF and a local IP. This address is configured by a custom startup script to give me a broadcast address for WOL while using VPN. Neither Asus nor FF appeared in the list of connected clients in the previous firmware so I fear regression may be the only option.

Based on this description, maybe affected by certain special character in Clients Name in the list.

You can double click on the Clients Name in the Network Map list to change the name. What if you change all to alphanumeric, underscore and hyphen only, without space or special characters?
 
Second day running 384.9 in AC-86U. Hit by these at midnight. Internet was disconnected, but it managed to auto-reconnect 2 hours later. Not sure whether it was ISP problem or the router problem. Keep monitoring...

Feb 11 01:57:36 pppd[1040]: Serial link appears to be disconnected.
Feb 11 01:57:36 odhcp6c[1518]: Failed to send DHCPV6 message to ff02::1:2 (Network is unreachable)
Feb 11 01:57:42 pppd[1040]: Connection terminated.
Feb 11 01:57:42 pppd[1040]: Modem hangup
Feb 11 01:58:27 pppd[1040]: Timeout waiting for PADO packets
Feb 11 01:59:42 pppd[1040]: Timeout waiting for PADO packets
Feb 11 02:00:57 pppd[1040]: Timeout waiting for PADO packets
Feb 11 02:02:13 pppd[1040]: Timeout waiting for PADO packets
Feb 11 02:03:28 pppd[1040]: Timeout waiting for PADO packets
Feb 11 02:04:43 pppd[1040]: Timeout waiting for PADO packets
Feb 11 02:05:58 pppd[1040]: Timeout waiting for PADO packets
.
.
.
Feb 11 03:54:54 pppd[1040]: Timeout waiting for PADO packets
Feb 11 03:56:10 pppd[1040]: Timeout waiting for PADO packets
Feb 11 03:57:25 pppd[1040]: Timeout waiting for PADO packets
Feb 11 03:58:40 pppd[1040]: Timeout waiting for PADO packets
Feb 11 03:59:55 pppd[1040]: Timeout waiting for PADO packets
Feb 11 03:59:58 pppd[1040]: Connected to 5c:45:xx:xx:xx:xx via interface br1
Feb 11 03:59:58 pppd[1040]: Connect: ppp0 <--> br1
Feb 11 04:00:01 pppd[1040]: PAP authentication succeeded
Feb 11 04:00:01 pppd[1040]: peer from calling number 5C:45:xx:xx:xx:xx authorized
Feb 11 04:00:01 pppd[1040]: local LL address fe80::59a1:xxxx:xxxx:xxxx
Feb 11 04:00:01 pppd[1040]: remote LL address fe80::5e45:xxxx:xxxx:xxxx
Feb 11 04:00:01 rc_service: ipv6-up 13958:notify_rc start_dhcp6c
Feb 11 04:00:01 pppd[1040]: local IP address xxx.xxx.xxx.xxx
Feb 11 04:00:01 pppd[1040]: remote IP address 10.xxx.xxx.xxx
Feb 11 04:00:01 rc_service: ip-up 13963:notify_rc start_firewall
Feb 11 04:00:01 wan: finish adding multi routes
Feb 11 04:00:01 nat: apply nat rules (/tmp/nat_rules_ppp0_br1)
 
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.

Why doesn't this remove entries in the syslog that occurred several days prior?
 
Why doesn't this remove entries in the syslog that occurred several days prior?
Dunno. Nothing in that is at all time-constrained. sed should go through file line by line and delete the relevant lines.
 
Every second counts when you're reporting out router uptime :D

Agreed. Pretty high change almost everyone on this forum is a bit paranoid about the router, therefore, a full second makes a big difference, LOL
 
Dunno. Nothing in that is at all time-constrained. sed should go through file line by line and delete the relevant lines.
The /tmp/syslog.log-1 is prepended to /tmp/syslog.log when displaying in the GUI. So you need to get both files at least the first time. Then the main one will rotate to the -1 file later.
 
I have many errors in RT-AC87U with the new firmware version 384.9 that I did not previously have. I've lost SIP connectivity from outside using OpenVPN.

Summary log:

avahi-daemon[1147]: WARNING: No NSS support for mDNS detected, consider installing nss-mdns!
...
Skynet: [%] Startup Initiated... ( skynetloc=/tmp/mnt/sda2/skynet )
kernel: sizeof forward pkt param = 192
ovpn-server1[960]: event_wait : Interrupted system call (code=4)
kernel: Interface tun21 doesn't exist
kernel: Interface tap21 doesn't exist
crond[267]: time disparity of 405016 minutes detected
ovpn-server1[1664]: Could not determine IPv4/IPv6 protocol. Using AF_INET6
These are perfectly normal entries.

Sent from my P027 using Tapatalk
 
AiProtection has never actually logged anything in the router GUI, even when it blocks something... nor does it send email (yes I supplied the gmail app password as credentials), and there's nothing to indicate a failed attempt to send email when the attempts to known bad sites get blocked by AiProtection.

Maybe it's something about the AC68U that's different from other hardware, or something else going on, but...

First post :
Please review the changelog for more details.
There is a number of known issues in this release that cannot be fixed at this time:
(3) No IPS events logged (bug in Asus's code, IPS should work, just fails to log hits)
(4) Users failing to read changelogs will probably complain about the above issues. (Outside of my control).
 
First post :
Please review the changelog for more details.
There is a number of known issues in this release that cannot be fixed at this time:
(3) No IPS events logged (bug in Asus's code, IPS should work, just fails to log hits)
(4) Users failing to read changelogs will probably complain about the above issues. (Outside of my control).
What about the lack of email being sent? (Sorry if I mentioned one thing that was noted in the changelog... though if it had mentioned "IPS from AiProtection" maybe I'd have noticed it as well)
 
What about the lack of email being sent? (Sorry if I mentioned one thing that was noted in the changelog... though if it had mentioned "IPS from AiProtection" maybe I'd have noticed it as well)

If nothing is logged how would there be an email? The reporting system is broken.
 
Installed on my 86u everything working fine only thing was hunting down where "dns.msftncsi.com" was hiding as it sends my PiHole into meltdown (just had to tick option DNS Query then remove info then save then untick and save again", not sure if it had anything to do with it but my Internet status also came up as being connected after also

I know its a known bug with network map being a bit temperamental but after setting a couple of static ip address manually in LAN - DHCP Server that looks like it's working ok now as well
 

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

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