[beta] Asuswrt-Merlin 384.17 beta is out

[RMerlin]

However, I have the list of ciphers set and that error (no local cipher) ocurrs.

Just ignore it, it's simply debug logging.

 

[maghuro]

Just ignore it, it's simply debug logging.

OCD

 

[Deleted member 22229]

Just ignore it, it's simply debug logging.

Is Asus aware of the debugging issues trashing peoples logs ? This has gone on way longer then expected and it's getting old. This makes finding things that are important virtually impossible. It truly really is at this point unexceptable not to mention highly annoying.

 

[SomeWhereOverTheRainBow]

Is Asus aware of the debugging issues trashing peoples logs ? This has gone on way longer then expected and it's getting old. This makes finding things that are important virtually impossible. It truly really is at this point unexceptable not to mention highly annoying.

i take it you are not apart of the debug-forever-logs fan club..

I agree, the "fake"-error logs get annoying when trying to track down any critical issues.

 

[Deleted member 22229]

i take it you are not apart of the debug-forever-logs fan club..

In a word NO.

 

[ppfoong]

Will this release include 81352 fix, which source code is available almost at the same time when this beta 17 is announced?

 

[SomeWhereOverTheRainBow]

Will this release include 81352 fix, which source code is available almost at the same time when this beta 17 is announced?

 

[tyspeed42]

Upgraded from AC86U 384.2 to 384.17 beta so far no issues at all, no complains from the fam, so we good.

 

[DelBierzo]

I have a problem in fw 384.16, and I do not know if it is a matter of windows 10 or the fw itself and if in 384.17b1 it is solved or can be solved.

Using NFS Exports, i can create folders without problem but cannot rename them.

 

[thelonelycoder]

Make sure you are 100% positive that it won't break anything, as I intend to push final releases as early as this weekend. Otherwise, best to hold off for 384.18.

I'll pass on this update for amtm, but for other reasons.

 

[Blacklistedcard]

Upgraded both my AC86U AND AC87U. No problems so far. I did notice this in the AC86U logfile, which is the first time seeing this.

Apr 25 08:35:14 RT-AC86U-F210 kernel: net_ratelimit: 645 callbacks suppressed
Apr 25 08:35:14 RT-AC86U-F210 kernel: protocol 0800 is buggy, dev eth6
Apr 25 08:35:14 RT-AC86U-F210 kernel: protocol 0800 is buggy, dev eth5
Apr 25 08:35:14 RT-AC86U-F210 kernel: protocol 0800 is buggy, dev eth4
Apr 25 08:35:14 RT-AC86U-F210 kernel: protocol 0800 is buggy, dev eth3
Apr 25 08:35:14 RT-AC86U-F210 kernel: protocol 0800 is buggy, dev eth2
Apr 25 08:35:14 RT-AC86U-F210 kernel: protocol 0800 is buggy, dev eth6
Apr 25 08:35:14 RT-AC86U-F210 kernel: protocol 0800 is buggy, dev eth5
Apr 25 08:35:14 RT-AC86U-F210 kernel: protocol 0800 is buggy, dev eth4
Apr 25 08:35:14 RT-AC86U-F210 kernel: protocol 0800 is buggy, dev eth3
Apr 25 08:35:14 RT-AC86U-F210 kernel: protocol 0800 is buggy, dev eth2
Apr 25 08:35:19 RT-AC86U-F210 kernel: net_ratelimit: 475 callbacks suppressed
Apr 25 08:35:19 RT-AC86U-F210 kernel: protocol 0800 is buggy, dev eth6
Apr 25 08:35:19 RT-AC86U-F210 kernel: protocol 0800 is buggy, dev eth5
Apr 25 08:35:19 RT-AC86U-F210 kernel: protocol 0800 is buggy, dev eth4
Apr 25 08:35:19 RT-AC86U-F210 kernel: protocol 0800 is buggy, dev eth3
Apr 25 08:35:19 RT-AC86U-F210 kernel: protocol 0800 is buggy, dev eth2
Apr 25 08:35:19 RT-AC86U-F210 kernel: protocol 0800 is buggy, dev eth6
Apr 25 08:35:19 RT-AC86U-F210 kernel: protocol 0800 is buggy, dev eth5
Apr 25 08:35:19 RT-AC86U-F210 kernel: protocol 0800 is buggy, dev eth4
Apr 25 08:35:19 RT-AC86U-F210 kernel: protocol 0800 is buggy, dev eth3
Apr 25 08:35:19 RT-AC86U-F210 kernel: protocol 0800 is buggy, dev eth2
Apr 25 08:35:24 RT-AC86U-F210 kernel: net_ratelimit: 545 callbacks suppressed
Apr 25 08:35:24 RT-AC86U-F210 kernel: protocol 0800 is buggy, dev eth6
Apr 25 08:35:24 RT-AC86U-F210 kernel: protocol 0800 is buggy, dev eth5
Apr 25 08:35:24 RT-AC86U-F210 kernel: protocol 0800 is buggy, dev eth4
Apr 25 08:35:24 RT-AC86U-F210 kernel: protocol 0800 is buggy, dev eth3
Apr 25 08:35:24 RT-AC86U-F210 kernel: protocol 0800 is buggy, dev eth2
Apr 25 08:35:24 RT-AC86U-F210 kernel: protocol 0800 is buggy, dev eth6
Apr 25 08:35:24 RT-AC86U-F210 kernel: protocol 0800 is buggy, dev eth5
Apr 25 08:35:24 RT-AC86U-F210 kernel: protocol 0800 is buggy, dev eth4
Apr 25 08:35:24 RT-AC86U-F210 kernel: protocol 0800 is buggy, dev eth3
Apr 25 08:35:24 RT-AC86U-F210 kernel: protocol 0800 is buggy, dev eth2

 

[MDM]

All working fine on mine RT-AC87U.
Tnx RMerlin!

 

[Intrepid2007]

I installed the beta version on my RT-AX88U router..
After 24 hours everything is still working fine!

On my AiMesh node (also an AX88U) I have the latest version of the stock firmware installed, all running fine!

 

[RMerlin]

Is Asus aware of the debugging issues trashing peoples logs ?

Yes, they were notified back when it was broken and was ignoring loglvels. No idea if that specific bug was fixed, but the presence of debugging info is not a bug in itself - it's what a system log is intended for.

It truly really is at this point unexceptable not to mention highly annoying.

If your clients keep disconnecting and reconnecting, then you need to troubleshoot your clients... Here is the content of my own system log for the entire last day:

Apr 24 01:49:18 miniupnpd[1672]: remove port mapping 33467 UDP because it has expired
Apr 24 01:49:18 miniupnpd[1672]: remove port mapping 33467 TCP because it has expired
Apr 24 01:49:21 miniupnpd[1672]: upnp_event_process_notify: connect(192.168.10.100:2869): No route to host
Apr 24 01:49:21 miniupnpd[1672]: upnpevents_processfds: 0x60c690, remove subscriber uuid:b1d58a3c-7604-4933-8267-519bd3ef8fc1 after an ERROR cb: http://192.168.10.100:2869/upnp/eventing/deegdbrknu
Apr 24 10:01:30 miniupnpd[1672]: upnp_event_recv: recv(): Connection reset by peer
Apr 24 10:01:30 miniupnpd[1672]: upnpevents_processfds: 0x60c690, remove subscriber uuid:36c99eef-e25d-4258-9eaf-1c1f0740b943 after an ERROR cb: http://192.168.10.100:2869/upnp/eventing/idnuyvxoxa
Apr 24 12:27:20 rc_service: httpd 1163:notify_rc start_autodet
Apr 24 12:27:21 rc_service: httpd 1163:notify_rc start_webs_update
Apr 24 16:28:33 dropbear[32037]: Password auth succeeded for 'admin' from 192.168.10.100:12052
Apr 24 16:33:31 dropbear[32486]: Password auth succeeded for 'admin' from 192.168.10.106:58030

Also, have you ever looked at the syslog of any CentOS7 server? systemd will generate log entries every few minutes, and this is considered normal. Here's a sample of just the last 2 hours of my very lightly used pihole VM:

Apr 25 12:00:01 pihole systemd: Created slice User Slice of root.
Apr 25 12:00:01 pihole systemd: Started Session 1775 of user root.
Apr 25 12:00:01 pihole systemd: Removed slice User Slice of root.
Apr 25 12:01:01 pihole systemd: Created slice User Slice of root.
Apr 25 12:01:01 pihole systemd: Started Session 1776 of user root.
Apr 25 12:01:01 pihole systemd: Removed slice User Slice of root.
Apr 25 12:10:01 pihole systemd: Created slice User Slice of root.
Apr 25 12:10:01 pihole systemd: Started Session 1777 of user root.
Apr 25 12:10:01 pihole systemd: Removed slice User Slice of root.
Apr 25 12:20:01 pihole systemd: Created slice User Slice of root.
Apr 25 12:20:01 pihole systemd: Started Session 1778 of user root.
Apr 25 12:20:02 pihole systemd: Removed slice User Slice of root.
Apr 25 12:30:01 pihole systemd: Created slice User Slice of root.
Apr 25 12:30:01 pihole systemd: Started Session 1779 of user root.
Apr 25 12:30:01 pihole systemd: Removed slice User Slice of root.
Apr 25 12:40:01 pihole systemd: Created slice User Slice of root.
Apr 25 12:40:01 pihole systemd: Started Session 1780 of user root.
Apr 25 12:40:01 pihole systemd: Removed slice User Slice of root.
Apr 25 12:50:01 pihole systemd: Created slice User Slice of root.
Apr 25 12:50:01 pihole systemd: Started Session 1781 of user root.
Apr 25 12:50:01 pihole systemd: Removed slice User Slice of root.
Apr 25 13:00:01 pihole systemd: Created slice User Slice of root.
Apr 25 13:00:01 pihole systemd: Started Session 1782 of user root.
Apr 25 13:00:01 pihole systemd: Removed slice User Slice of root.
Apr 25 13:01:01 pihole systemd: Created slice User Slice of root.
Apr 25 13:01:01 pihole systemd: Started Session 1783 of user root.
Apr 25 13:01:01 pihole systemd: Removed slice User Slice of root.
Apr 25 13:10:01 pihole systemd: Created slice User Slice of root.
Apr 25 13:10:01 pihole systemd: Started Session 1784 of user root.
Apr 25 13:10:01 pihole systemd: Removed slice User Slice of root.
Apr 25 13:20:01 pihole systemd: Created slice User Slice of root.
Apr 25 13:20:01 pihole systemd: Started Session 1785 of user root.
Apr 25 13:20:01 pihole systemd: Removed slice User Slice of root.
Apr 25 13:30:01 pihole systemd: Created slice User Slice of root.
Apr 25 13:30:01 pihole systemd: Started Session 1786 of user root.
Apr 25 13:30:01 pihole systemd: Removed slice User Slice of root.
Apr 25 13:40:01 pihole systemd: Created slice User Slice of root.
Apr 25 13:40:01 pihole systemd: Started Session 1787 of user root.
Apr 25 13:40:01 pihole systemd: Removed slice User Slice of root.
Apr 25 13:50:01 pihole systemd: Created slice User Slice of root.
Apr 25 13:50:01 pihole systemd: Started Session 1788 of user root.
Apr 25 13:50:01 pihole systemd: Removed slice User Slice of root.
Apr 25 13:51:47 pihole systemd: Created slice User Slice of root.
Apr 25 13:51:47 pihole systemd: Started Session 1789 of user root.
Apr 25 13:51:47 pihole systemd-logind: New session 1789 of user root.

Also, have a look at any Windows Event logs. Same thing.

System logs are intended for containing activity info, not to present a clean summary of things. You need to use some form of filter for that kind of usage.

 

[RMerlin]

I agree, the "fake"-error logs get annoying when trying to track down any critical issues.

If you don't want to see notifications, then don't keep your logging level to notice... Syslog uses priority levels for log entries. If you only want to see critical issues, then set log filtering to critical. And then don't complain if you are missing on notify level entries not appearing...


Seriously guys, you are complaining about complete non-issues here, especially when you already have all the configuration settings needed to change it.

 

[RMerlin]

Will this release include 81352 fix, which source code is available almost at the same time when this beta 17 is announced?

Read the changelog, 81352 was already merged many weeks ago, and was included in 384.16...

 

[DonnyJohnny]

@RMerlin
Version 3.0.0.4.385.20433 2020/04/22 1.14 GBytes
GPL of ASUS RT-AC68U for firmware 3.0.0.4.385.20433
is out.

Hope to see the Krook patched in the RT-AC68U soon.

Thank you.

 

[AntonK]

If you don't want to see notifications, then don't keep your logging level to notice... Syslog uses priority levels for log entries. If you only want to see critical issues, then set log filtering to critical. And then don't complain if you are missing on notify level entries not appearing...


Seriously guys, you are complaining about complete non-issues here, especially when you already have all the configuration settings needed to change it.

One question regarding the setting of the system log filter. When scripts like Skynet, Diversion, and uiDivStats became widely available, I think I remember the issue coming up where if you didn't have your System Log filter settings set to the default (pic attached), that you wouldn't get the stats you thought were supposed to be getting because one or more of the scripts relies on the System Log for that. Is that correct?

Thanks,
Anton

 

[MacG32]

Just checked my log and OpenVPN only excluded the first 3 IPs from forced DNS routing. I have 27 IPs/ranges listed in the Rules for routing client traffic through the tunnel. 20 IPs are excluded and 7 ranges are included. This happened on a power off and on again.

When I turned the Service state off and on again for the VPN client, it restarted up normally.

 

[RMerlin]

One question regarding the setting of the system log filter. When scripts like Skynet, Diversion, and uiDivStats became widely available, I think I remember the issue coming up where if you didn't have your System Log filter settings set to the default (pic attached), that you wouldn't get the stats you thought were supposed to be getting because one or more of the scripts relies on the System Log for that. Is that correct?

It depends the priority level at which a log entry is added. With syslog, when you add something to the log, you specify its priority. Anything added by the core asuswrt code itself will be at the "Default message log level" because its built-in logmessage() function does not let you specify a priority. Log entries coming from other daemons like dnsmasq or miniupnpd however will log messages at various levels, based on whether they are, for example, notices, errors, warnings, etc...

So, if you set your filter to only report events of a higher priority, then these scripts will not be able to access the log entries they rely on.