Release ASUS RT-AX86U Firmware version 3.0.0.4.386_49447 (2022/06/20)

[Tech9]

This one does, but the same set power is applied to all channels. If you set it to Power Save, the radio works with one stream only.

 

[Jbennett360]

So update or not?

Did we find out about the log spamming at all?

 

[OzarkEdge]

So update or not?

Did we find out about the log spamming at all?

The visible log spans 24+ hours here. I don't mind it... gives my router something to do in its spare time.

OE

 

[Tech9]

My log is full of DHCPDISCOVER, DHCPOFFER, DHCPINFORM, DHCPACK, CONSOLE and group key handshakes. Hard to find what's important.

Setting log level to 6 takes care of DHCP related messages.

nvram set log_level=6
nvram commit
service restart_logger

CONSOLE messages remain. I don't want to change it to 5 because it will hide vpnserver messages. Log server with custom filter works better.

 

[tallytr]

So update or not?

Did we find out about the log spamming at all?

Update. Exactly the same for me as before...with whatever was changed

 

[tomtsang]

I believed this picture would be good to tell the story.

 

[OzarkEdge]

I believed this picture would be good to tell the story.
View attachment 42184

It suggests the user can block ads OR protect family OR go fast OR be safe OR respect privacy OR you're on your own... a pleasant interface becomes sad commentary. I'm sure I'm reading too much into it.

OE

 

[bbunge]

It suggests the user can block ads OR protect family OR go fast OR be safe OR respect privacy OR you're on your own... a pleasant interface becomes sad commentary. I'm sure I'm reading too much into it.

OE

No, just more smoke and mirrors to give a false sense of security...

 

[OzarkEdge]

No, just more smoke and mirrors to give a false sense of security...

I meant, I want it all... not just one OR the other.

OE

 

[Paliv]

It suggests the user can block ads OR protect family OR go fast OR be safe OR respect privacy OR you're on your own... a pleasant interface becomes sad commentary. I'm sure I'm reading too much into it.

OE

Cleanbrowsing falls into the most of their categories. Maybe they are you’re best bet.

 

[Tech9]

I actually hate the logs in this firmware.

Jun 26 09:43:15 kernel: CONSOLE: 178374.991 wl1.0: wlc_ampdu_resp_timeout: 70:66:55:ec:42:4d: tid 0 cleaning up resp tid waiting for seq 0xf99 for 200 ms
Jun 26 09:44:40 kernel: CONSOLE: 178459.091 wl1.0: wlc_ampdu_resp_timeout: 70:66:55:ec:42:4d: tid 0 cleaning up resp tid waiting for seq 0x8c3 for 200 ms
Jun 26 09:44:54 kernel: CONSOLE: 178473.424 wl1.0: wlc_ampdu_resp_timeout: 70:66:55:ec:42:4d: tid 0 cleaning up resp tid waiting for seq 0xbb1 for 200 ms
Jun 26 09:44:55 kernel: CONSOLE: 178473.826 wl1.0: wlc_ampdu_resp_timeout: 70:66:55:ec:42:4d: tid 0 cleaning up resp tid waiting for seq 0xbb4 for 200 ms
Jun 26 09:46:24 kernel: CONSOLE: 178562.435 wl1.0: wlc_ampdu_resp_timeout: 70:66:55:ec:42:4d: tid 0 cleaning up resp tid waiting for seq 0x1cf for 200 ms
Jun 26 09:46:29 kernel: CONSOLE: 178567.938 wl1.0: wlc_ampdu_resp_timeout: 70:66:55:ec:42:4d: tid 0 cleaning up resp tid waiting for seq 0x90b for 200 ms
Jun 26 09:47:05 kernel: CONSOLE: 178603.478 wl1.0: wlc_ampdu_resp_timeout: 70:66:55:ec:42:4d: tid 0 cleaning up resp tid waiting for seq 0xca9 for 200 ms
Jun 26 09:47:33 kernel: CONSOLE: 178631.520 wl1.0: wlc_ampdu_resp_timeout: 70:66:55:ec:42:4d: tid 0 cleaning up resp tid waiting for seq 0xa36 for 200 ms
Jun 26 09:47:44 kernel: CONSOLE: 178642.508 wl1.0: wlc_ampdu_resp_timeout: 70:66:55:ec:42:4d: tid 0 cleaning up resp tid waiting for seq 0x348 for 200 ms
Jun 26 09:47:46 kernel: CONSOLE: 178643.910 wl1.0: wlc_ampdu_resp_timeout: 70:66:55:ec:42:4d: tid 0 cleaning up resp tid waiting for seq 0x3f0 for 200 ms
Jun 26 09:47:48 kernel: CONSOLE: 178646.260 wl1.0: wlc_ampdu_resp_timeout: 70:66:55:ec:42:4d: tid 0 cleaning up resp tid waiting for seq 0x63f for 200 ms
Jun 26 09:48:11 kernel: CONSOLE: 178669.348 wl1.0: wlc_ampdu_resp_timeout: 70:66:55:ec:42:4d: tid 0 cleaning up resp tid waiting for seq 0xa6a for 200 ms
Jun 26 09:48:43 kernel: CONSOLE: 178701.259 wl1.0: wlc_ampdu_resp_timeout: 70:66:55:ec:42:4d: tid 0 cleaning up resp tid waiting for seq 0x458 for 200 ms
Jun 26 09:49:12 kernel: CONSOLE: 178729.783 wl1.0: wlc_ampdu_resp_timeout: 70:66:55:ec:42:4d: tid 0 cleaning up resp tid waiting for seq 0xdfb for 200 ms
Jun 26 09:49:14 kernel: CONSOLE: 178732.100 wl1.0: wlc_ampdu_resp_timeout: 70:66:55:ec:42:4d: tid 0 cleaning up resp tid waiting for seq 0xf5f for 200 ms
Jun 26 09:49:15 kernel: CONSOLE: 178733.353 wl1.0: wlc_ampdu_resp_timeout: 70:66:55:ec:42:4d: tid 0 cleaning up resp tid waiting for seq 0x4f for 200 ms
Jun 26 09:49:43 kernel: CONSOLE: 178760.663 wl1.0: wlc_ampdu_resp_timeout: 70:66:55:ec:42:4d: tid 0 cleaning up resp tid waiting for seq 0x88a for 200 ms
Jun 26 09:49:58 kernel: CONSOLE: 178775.612 wl1.0: wlc_ampdu_resp_timeout: 70:66:55:ec:42:4d: tid 0 cleaning up resp tid waiting for seq 0xbf9 for 200 ms
Jun 26 09:50:23 kernel: CONSOLE: 178800.593 wl1.0: wlc_ampdu_resp_timeout: 70:66:55:ec:42:4d: tid 0 cleaning up resp tid waiting for seq 0xf99 for 200 ms
Jun 26 09:53:23 kernel: CONSOLE: 178980.378 wl1.0: wlc_ampdu_resp_timeout: 70:66:55:ec:42:4d: tid 0 cleaning up resp tid waiting for seq 0x1e4 for 200 ms
Jun 26 09:53:24 kernel: CONSOLE: 178980.846 wl1.0: wlc_ampdu_resp_timeout: 70:66:55:ec:42:4d: tid 0 cleaning up resp tid waiting for seq 0x29a for 200 ms
Jun 26 09:53:55 kernel: CONSOLE: 179011.763 wl1.0: wlc_ampdu_resp_timeout: 70:66:55:ec:42:4d: tid 0 cleaning up resp tid waiting for seq 0xc70 for 200 ms
Jun 26 09:54:06 kernel: CONSOLE: 179022.835 wl1.0: wlc_ampdu_resp_timeout: 70:66:55:ec:42:4d: tid 0 cleaning up resp tid waiting for seq 0xd95 for 200 ms

This MAC is my HP laptop. No idea what is going on. Never seen this before. This goes for pages long.

 

[Paliv]

I actually hate the logs in this firmware.

Jun 26 09:43:15 kernel: CONSOLE: 178374.991 wl1.0: wlc_ampdu_resp_timeout: 70:66:55:ec:42:4d: tid 0 cleaning up resp tid waiting for seq 0xf99 for 200 ms
Jun 26 09:44:40 kernel: CONSOLE: 178459.091 wl1.0: wlc_ampdu_resp_timeout: 70:66:55:ec:42:4d: tid 0 cleaning up resp tid waiting for seq 0x8c3 for 200 ms
Jun 26 09:44:54 kernel: CONSOLE: 178473.424 wl1.0: wlc_ampdu_resp_timeout: 70:66:55:ec:42:4d: tid 0 cleaning up resp tid waiting for seq 0xbb1 for 200 ms
Jun 26 09:44:55 kernel: CONSOLE: 178473.826 wl1.0: wlc_ampdu_resp_timeout: 70:66:55:ec:42:4d: tid 0 cleaning up resp tid waiting for seq 0xbb4 for 200 ms
Jun 26 09:46:24 kernel: CONSOLE: 178562.435 wl1.0: wlc_ampdu_resp_timeout: 70:66:55:ec:42:4d: tid 0 cleaning up resp tid waiting for seq 0x1cf for 200 ms
Jun 26 09:46:29 kernel: CONSOLE: 178567.938 wl1.0: wlc_ampdu_resp_timeout: 70:66:55:ec:42:4d: tid 0 cleaning up resp tid waiting for seq 0x90b for 200 ms
Jun 26 09:47:05 kernel: CONSOLE: 178603.478 wl1.0: wlc_ampdu_resp_timeout: 70:66:55:ec:42:4d: tid 0 cleaning up resp tid waiting for seq 0xca9 for 200 ms
Jun 26 09:47:33 kernel: CONSOLE: 178631.520 wl1.0: wlc_ampdu_resp_timeout: 70:66:55:ec:42:4d: tid 0 cleaning up resp tid waiting for seq 0xa36 for 200 ms
Jun 26 09:47:44 kernel: CONSOLE: 178642.508 wl1.0: wlc_ampdu_resp_timeout: 70:66:55:ec:42:4d: tid 0 cleaning up resp tid waiting for seq 0x348 for 200 ms
Jun 26 09:47:46 kernel: CONSOLE: 178643.910 wl1.0: wlc_ampdu_resp_timeout: 70:66:55:ec:42:4d: tid 0 cleaning up resp tid waiting for seq 0x3f0 for 200 ms
Jun 26 09:47:48 kernel: CONSOLE: 178646.260 wl1.0: wlc_ampdu_resp_timeout: 70:66:55:ec:42:4d: tid 0 cleaning up resp tid waiting for seq 0x63f for 200 ms
Jun 26 09:48:11 kernel: CONSOLE: 178669.348 wl1.0: wlc_ampdu_resp_timeout: 70:66:55:ec:42:4d: tid 0 cleaning up resp tid waiting for seq 0xa6a for 200 ms
Jun 26 09:48:43 kernel: CONSOLE: 178701.259 wl1.0: wlc_ampdu_resp_timeout: 70:66:55:ec:42:4d: tid 0 cleaning up resp tid waiting for seq 0x458 for 200 ms
Jun 26 09:49:12 kernel: CONSOLE: 178729.783 wl1.0: wlc_ampdu_resp_timeout: 70:66:55:ec:42:4d: tid 0 cleaning up resp tid waiting for seq 0xdfb for 200 ms
Jun 26 09:49:14 kernel: CONSOLE: 178732.100 wl1.0: wlc_ampdu_resp_timeout: 70:66:55:ec:42:4d: tid 0 cleaning up resp tid waiting for seq 0xf5f for 200 ms
Jun 26 09:49:15 kernel: CONSOLE: 178733.353 wl1.0: wlc_ampdu_resp_timeout: 70:66:55:ec:42:4d: tid 0 cleaning up resp tid waiting for seq 0x4f for 200 ms
Jun 26 09:49:43 kernel: CONSOLE: 178760.663 wl1.0: wlc_ampdu_resp_timeout: 70:66:55:ec:42:4d: tid 0 cleaning up resp tid waiting for seq 0x88a for 200 ms
Jun 26 09:49:58 kernel: CONSOLE: 178775.612 wl1.0: wlc_ampdu_resp_timeout: 70:66:55:ec:42:4d: tid 0 cleaning up resp tid waiting for seq 0xbf9 for 200 ms
Jun 26 09:50:23 kernel: CONSOLE: 178800.593 wl1.0: wlc_ampdu_resp_timeout: 70:66:55:ec:42:4d: tid 0 cleaning up resp tid waiting for seq 0xf99 for 200 ms
Jun 26 09:53:23 kernel: CONSOLE: 178980.378 wl1.0: wlc_ampdu_resp_timeout: 70:66:55:ec:42:4d: tid 0 cleaning up resp tid waiting for seq 0x1e4 for 200 ms
Jun 26 09:53:24 kernel: CONSOLE: 178980.846 wl1.0: wlc_ampdu_resp_timeout: 70:66:55:ec:42:4d: tid 0 cleaning up resp tid waiting for seq 0x29a for 200 ms
Jun 26 09:53:55 kernel: CONSOLE: 179011.763 wl1.0: wlc_ampdu_resp_timeout: 70:66:55:ec:42:4d: tid 0 cleaning up resp tid waiting for seq 0xc70 for 200 ms
Jun 26 09:54:06 kernel: CONSOLE: 179022.835 wl1.0: wlc_ampdu_resp_timeout: 70:66:55:ec:42:4d: tid 0 cleaning up resp tid waiting for seq 0xd95 for 200 ms

This MAC is my HP laptop. No idea what is going on. Never seen this before. This goes for pages long.

I have a feeling ASUS doesn’t worry too much about the few power users who read the log regularly. I agree it’s a mess, but since I’m not well versed in log messages anyway I only look at it when I have a problem. Hopefully they change this behavior if enough people complain.

 

[Tech9]

One observation, someone may be interested.

If you want to see this in Traffic Analyzer:

Instead of this:

Block Google's QUIC protocol in Firewall:

Some of the reasons why you may want to do it:

How Google's QUIC Protocol Impacts Network Security and Reporting

Google's QUIC protocol is designed to make the web faster and more efficient. Unfortunately, Firewalls do not currently recognize QUIC traffic as web traffic, leaving a gaping hole in your network's security and reporting capabilities. This article describes how you can resolve these issues...

www.fastvue.co

In general it doesn't matter for average users.

 

[Paliv]

One observation, someone may be interested

If you want to see this in Traffic Analyzer:

View attachment 42191

Instead of this:

View attachment 42190

Block Google QUIC protocol in Firewall:

View attachment 42192

Some of the reasons why you may want to do it:

How Google's QUIC Protocol Impacts Network Security and Reporting

Google's QUIC protocol is designed to make the web faster and more efficient. Unfortunately, Firewalls do not currently recognize QUIC traffic as web traffic, leaving a gaping hole in your network's security and reporting capabilities. This article describes how you can resolve these issues...

www.fastvue.co

In general it doesn't matter for average users.

Thank you!!

 

[OzarkEdge]

Cleanbrowsing falls into the most of their categories. Maybe they are you’re best bet.

I don't need a nanny state router here... some things are user choice... just no ads, no crooks, speed and privacy, thank you.

OE

 

[Tech9]

I have a feeling ASUS doesn’t worry too much about the few power users

I'm not a power user, but I just want to be able to see some things in logs. AX86U log is a jungle adventure.

This is my AC86U log for 24 period on current latest Asuswrt 48260 firmware for comparison:

Jun 25 04:46:02 WATCHDOG: [FAUPGRADE][auto_firmware_check:(7669)]do webs_update
Jun 25 04:46:05 WATCHDOG: [FAUPGRADE][auto_firmware_check:(7687)]retrieve firmware information
Jun 25 04:46:05 WATCHDOG: [FAUPGRADE][auto_firmware_check:(7702)]fimrware update check first time
Jun 25 04:46:05 WATCHDOG: [FAUPGRADE][auto_firmware_check:(7733)]no need to upgrade firmware
Jun 25 04:46:34 WATCHDOG: [FAUPGRADE][auto_firmware_check:(7669)]do webs_update
Jun 25 04:46:34 WATCHDOG: [FAUPGRADE][auto_firmware_check:(7687)]retrieve firmware information
Jun 25 04:46:34 WATCHDOG: [FAUPGRADE][auto_firmware_check:(7707)]fimrware update check once
Jun 25 04:47:05 WATCHDOG: [FAUPGRADE][auto_firmware_check:(7669)]do webs_update
Jun 25 04:47:05 WATCHDOG: [FAUPGRADE][auto_firmware_check:(7687)]retrieve firmware information
Jun 25 04:47:05 WATCHDOG: [FAUPGRADE][auto_firmware_check:(7707)]fimrware update check once
Jun 25 04:47:34 WATCHDOG: [FAUPGRADE][auto_firmware_check:(7669)]do webs_update
Jun 25 04:47:34 WATCHDOG: [FAUPGRADE][auto_firmware_check:(7687)]retrieve firmware information
Jun 25 04:47:34 WATCHDOG: [FAUPGRADE][auto_firmware_check:(7702)]fimrware update check first time
Jun 25 04:47:34 WATCHDOG: [FAUPGRADE][auto_firmware_check:(7733)]no need to upgrade firmware
Jun 25 05:41:24 ahs: [read_json]Update ahs JSON file.
Jun 26 04:46:04 WATCHDOG: [FAUPGRADE][auto_firmware_check:(7669)]do webs_update
Jun 26 04:46:06 WATCHDOG: [FAUPGRADE][auto_firmware_check:(7687)]retrieve firmware information
Jun 26 04:46:06 WATCHDOG: [FAUPGRADE][auto_firmware_check:(7702)]fimrware update check first time
Jun 26 04:46:06 WATCHDOG: [FAUPGRADE][auto_firmware_check:(7733)]no need to upgrade firmware
Jun 26 04:46:36 WATCHDOG: [FAUPGRADE][auto_firmware_check:(7669)]do webs_update
Jun 26 04:46:36 WATCHDOG: [FAUPGRADE][auto_firmware_check:(7687)]retrieve firmware information
Jun 26 04:46:36 WATCHDOG: [FAUPGRADE][auto_firmware_check:(7707)]fimrware update check once
Jun 26 04:47:06 WATCHDOG: [FAUPGRADE][auto_firmware_check:(7669)]do webs_update
Jun 26 04:47:06 WATCHDOG: [FAUPGRADE][auto_firmware_check:(7687)]retrieve firmware information
Jun 26 04:47:06 WATCHDOG: [FAUPGRADE][auto_firmware_check:(7707)]fimrware update check once
Jun 26 04:47:36 WATCHDOG: [FAUPGRADE][auto_firmware_check:(7669)]do webs_update
Jun 26 04:47:36 WATCHDOG: [FAUPGRADE][auto_firmware_check:(7687)]retrieve firmware information
Jun 26 04:47:36 WATCHDOG: [FAUPGRADE][auto_firmware_check:(7702)]fimrware update check first time
Jun 26 04:47:36 WATCHDOG: [FAUPGRADE][auto_firmware_check:(7733)]no need to upgrade firmware
Jun 26 05:44:03 ahs: [read_json]Update ahs JSON file.

just no ads, no crooks, speed and privacy

AdGuard DNS is perhaps your best fit. I don't know how fast it is in your location. They have local servers here in Toronto.

 

[OzarkEdge]

One observation, someone may be interested.

If you want to see this in Traffic Analyzer:

View attachment 42191

Instead of this:

View attachment 42190

Block Google's QUIC protocol in Firewall:

View attachment 42192

Some of the reasons why you may want to do it:

How Google's QUIC Protocol Impacts Network Security and Reporting

Google's QUIC protocol is designed to make the web faster and more efficient. Unfortunately, Firewalls do not currently recognize QUIC traffic as web traffic, leaving a gaping hole in your network's security and reporting capabilities. This article describes how you can resolve these issues...

www.fastvue.co

In general it doesn't matter for average users.

That Google Chrome QUIC protocol does not appear to be active in MS Edge, built on Chromium.

OE

 

[OzarkEdge]

I actually hate the logs in this firmware.

I'll bet the extra logging will pass soon enough.

This MAC is my HP laptop. No idea what is going on. Never seen this before. This goes for pages long.

If just one client, then it may be worth knowing to someone... you, Apple, ASUS.

OE

 

[Tech9]

That Google Chrome QUIC protocol

It's not Google Chrome QUIC, but Google QUIC:

Microsoft Embracing Native QUIC in Newer Windows OSes and Edge Browser -- Redmondmag.com

Microsoft this week described QUIC, an Internet transport layer protocol alternative to the venerable Transmission Control Protocol (TCP), in an announcement.

redmondmag.com

If just one client, then it may be worth knowing to someone...

The laptop's Wi-Fi is working normally, >500Mbps speeds, but I still can't find what the log message means.

 

[KevTech]

Setting log level to 6 takes care of DHCP related messages.

The default level on stock is 6.
On merlin it is 7.
Could try 5 and see what happens.
Seems like Asus has left the debug messages on perhaps from when they were testing to see why the last firmware was bricking some routers.
Asus has done this before then corrected it in the next release.