[Release] Asuswrt-Merlin 384.9 is now available

[Xenus]

Please make cooler status go from 30 to 80, starting at 50 is too high

Mine goes from 40 to 90, take another look (FWIW: RT-AC87U). My wireless temps flatline but that's because I use a cooler.

 

[Butterfly Bones]

Interesting! I use PIA and I just added that line but it had to be formatted as such to be accepted, or the VPN would not come up.

pull-filter ignore "auth token"

Cheers!

OK, I was dead wrong on that, so I corrected the post above, the quotes ARE there around "auth token".
I was going from (defective) memory, it was gawdawful 0-dark-30 early, and I had not had caffiene yet. I know better than to post before coffee.

 

[SNR]

I get those from an iPhone, Apple watch, Pixel 2 XL, LG Watch Sport, Nexus 6, Huawei watch 1, Nexus 7, Kindle paperwhite, TP Link smart lights, Google Home Mini, Google Home Max, literally every wifi device I have connected to my network. all are 5G except the three TP Link bulbs, and none of them are switching networks.

Most of these event wireless client events are wakeup (Assoc) to see if they have commands, then sleep (Disassoc). I see those when devices leave home and later return. It is the wireless daemon logging events. Yes new in syslog, but I like the info rather than it being hidden behind the manufacturer "hidden" curtain

@RMerlin can we please have a firmware option added to disable logging of these WLCEVENTD events, like we currently have for DHCP/RA queries? Thanks...

 

[cmkelley]

@RMerlin can we please have a firmware option added to disable logging of these WLCEVENTD events, like we currently have for DHCP/RA queries? Thanks...

FYI, there is a script to install syslog-ng coming in a couple weeks that will install a filter to move the wlceventd messages to their own log file.

 

[SNR]

FYI, there is a script to install syslog-ng coming in a couple weeks that will install a filter to move the wlceventd messages to their own log file.

Thanks for that info, but I'm still hoping this feature can be added to the base Asuswrt-Merlin firmware. I'm not currently using any extra modules and I prefer not having to do that just for this issue.

 

[RMerlin]

@RMerlin can we please have a firmware option added to disable logging of these WLCEVENTD events, like we currently have for DHCP/RA queries? Thanks...

I can't "configure" it, it's done by a closed source daemon.

Just be patient, Asus are aware of the issue (it's actually a bug in their code where the daemon ignores the nvram that's supposed to control logging verbosity for that daemon).

It's a logfile, it's meant to contain info, not to be looked at constantly... You probably never looked at a CentOS 7 system log, with systemd generating log entries every couple of minutes.

 

[pablo11]

I can't "configure" it, it's done by a closed source daemon.

Just be patient, Asus are aware of the issue (it's actually a bug in their code where the daemon ignores the nvram that's supposed to control logging verbosity for that daemon).

It's a logfile, it's meant to contain info, not to be looked at constantly... You probably never looked at a CentOS 7 system log, with systemd generating log entries every couple of minutes.

Yep, I don't see why the big deal?
They are just log messages that were not visible previously.
Just because we can see them now, it makes absolutely no difference to performance / throughput.
Thanks again for your work [emoji106]

Sent from my BLA-L29 using Tapatalk

 

[SNR]

I can't "configure" it, it's done by a closed source daemon.

Just be patient, Asus are aware of the issue (it's actually a bug in their code where the daemon ignores the nvram that's supposed to control logging verbosity for that daemon).

That's good to know, thanks for that info!

It's a logfile, it's meant to contain info, not to be looked at constantly... You probably never looked at a CentOS 7 system log, with systemd generating log entries every couple of minutes.

Yes I have, thanks. I just prefer not to see anything on the System Log page unless it's worth paying attention to, and I would rather not fiddle with the default message log level to get it that way. Sort of like setting up a monitoring system to only notify you if something truly needs to be looked at, i.e. "No news is good news."

But yes, I can certainly wait for Asus to get it together (on this issue at least).

And no worries @pablo11 it's not a big deal.

Carry on guys!

 

[pablo11]

@SNR
ha ha yes, that's the point I was making [emoji106]

Sent from my BLA-L29 using Tapatalk

 

[G997]

Mine goes from 40 to 90, take another look (FWIW: RT-AC87U). My wireless temps flatline but that's because I use a cooler.

50 to 80 AX88U

 

[Keanu]

I updated few seconds ago and now every text field has white text on white background so I have to select the text to see the value. Any one else with this issue?

Looks like this is only in Chrome. Microsoft Edge seems OK.

EDIT: Sorry, fixed by deleting cached files.

 

[The Cool Dude]

Hello everyone.

RT-AC87U x 2

Just updated from 384.5 to 384.9 dirty flash. No issues.

Thank you RMerlin!

 

[Keanu]

OK, another strange thing I found. I see an asus device in my network with IP address 169.254.39.221 which I never saw before and I have no freaking idea what that is. My network is 192.168.1.0/24. On my router I can see a br0 device with IP 169.254.39.217. What the hell is this for? The mac address of this new asus devices does not equal the mac of my router, very strange.

 

[Zonkd]

OK, another strange thing I found. I see an asus device in my network with IP address 169.254.39.221 which I never saw before and I have no freaking idea what that is. My network is 192.168.1.0/24. On my router I can see a br0 device with IP 169.254.39.217. What the hell is this for? The mac address of this new asus devices does not equal the mac of my router, very strange.

https://serverfault.com/questions/132657/where-does-the-route-to-169-254-0-0-comes-from

“The 169.254.0.0/16 network is used for Automatic Private IP Addressing, or APIPA. If a DHCP client attempts to get an address, but fails to find a DHCP server after the timeout and retries period it will randomly assume an address from this network.”

So perhaps the device failed to get an IP, assigned it’s own, and then it’s been sent to the router. My networking knowledge is limited at this point in time but I wouldn’t be freaking out about this, just check all the devices on your network for their MAC addresses.

 

[MDM]

OK, another strange thing I found. I see an asus device in my network with IP address 169.254.39.221 which I never saw before and I have no freaking idea what that is. My network is 192.168.1.0/24. On my router I can see a br0 device with IP 169.254.39.217. What the hell is this for? The mac address of this new asus devices does not equal the mac of my router, very strange.

It is your internal WiFi antenna, I have the same... Asus one's to correct, it should not be seen.

 

[Keanu]

Thank you, I almost lost my mind searching for ASUS devices attached via wired connection to my network.
The mac address is exactly the one from "Wireless 5GHz MAC address" in the web UI.
This shouldn't be displayed in the client list.

 

[JIPG]

Updated successfully an RT AC-87U, resetting and introducing the configuration manually from scratch.

Everything is working OK, so thank you Eric for your efforts including our router in your list for this release. You has allowed us ( RT AC-87U users) to have the security fixes that are released for other routers (+ all your useful stuff, of course), so this has no price ...

I have a question that maybe someone with this router and updated to this release can answer: I have found in the network map that the some of the IP addresses indicated are wrong/messed (I have a manual assignation of IPs for all my devices, around 30, and some of them do not macth with the number assigned), and it is already reported in the first post as an ASUS problem ("unreliable network map"). The question is, is this mess affecting only to the network map showed IP numbers or it can affect also to the parental control (time scheduling , etc) rules?.
I guess "no", but just to be sure ...

In fact, also the data of IPs leases in "System Log" are wrong, as part of the leases are not shown at all (the ones with IP numbers messed).

Other router that I have as wireless AP, with static IP outside the range of the router DHCP server range (starting in 192.168.1.31), is not shown now, while it was shown before (with correct IP 192.168.1.2) with the FW 384.7_2.
I suppose this it is another side effect of the "unreliable" network map ...

 

[Artz]

@RMerlin so I tried everything to connect my Squeezbox Boom to RT-AC88U. I've reset the router by holding the reset button for 5 seconds to reset the router to factory settings. I then created a new SSID with the new name and tried to reconnect the Squeezbox Boom. Still same error "wireless encryption failure".

Then I tried to connect it to my old RT-AC66U (version 1). It connected in 2 second without any problems. It is running your last firmware.

Did something changed in the latest version which could have created this kind of problem? I have 2 other Squeezbox Radios. They connect without any problems, so is any other device in home.

 

[Tom Ames]

@RMerlin so I tried everything to connect my Squeezbox Boom to RT-AC88U. I've reset the router by holding the reset button for 5 seconds to reset the router to factory settings. I then created a new SSID with the new name and tried to reconnect the Squeezbox Boom. Still same error "wireless encryption failure".

Then I tried to connect it to my old RT-AC66U (version 1). It connected in 2 second without any problems. It is running your last firmware.

Did something changed in the latest version which could have created this kind of problem? I have 2 other Squeezbox Radios. They connect without any problems, so is any other device in home.

You might also try asking your question here: https://forums.slimdevices.com/forumdisplay.php?25-Squeezebox-Boom

 

[TheOldMan]

Still having problems with self-compilation of 384.9 build since it was released.

make[8]: *** No rule to make target '../../include/openssl/rc4.h', needed by 'eng_openssl.o'. Stop.

One of many errors... using both rsync and make clean.