386.5 Alpha1?

[Bent_wrench]

By hard reset do you mean reset to factory defaults?

Edit: Possibly Solved, I unplugged my Linksys range extender, and 5 GHz working on my phone and laptop. I was using the range extender with firmware 386.4 for my TP-Link IoT devices on 2.4 GHz. I'll try moving those back now. BTW, that weird RADIUS and de-auth message below was related to the Linksys. That is a fake MAC address.

Yes, following the Asus instructions for hard reset.

I've also reverted to the Asus stock firmware, latest version 3.0.0.4.386_47029-g38ccf74, still having issues with 5 GHz. My phone reports "limited connectivity". My laptop will connect to it, show it connected, but pass no internet traffic.

Edit: I disabled WPS. After that, the Nest cams all came up (on 5 GHz) and have been stable for 20 mins. They wouldn't even connect before. Laptop. TV, Phone still won't work properly, however.

In the syslog, I see a lot of RADIUS messages, I don't recall seeing these with older versions. AFAIK, I have not enabled RADIUS, I'm using WPA2-personal.

Feb 20 16:41:03 hostapd: eth6: STA 16:91:82:0c:8b:9c IEEE 802.11: associated
Feb 20 16:41:04 hostapd: eth6: STA 16:91:82:0c:8b:9c RADIUS: starting accounting session 216224046B965D62
Feb 20 16:41:04 hostapd: eth6: STA 16:91:82:0c:8b:9c WPA: pairwise key handshake completed (RSN)
Feb 20 16:41:18 dnsmasq-dhcp[1273]: DHCPDISCOVER(br0) 64:16:66:46:41:6e
Feb 20 16:41:18 dnsmasq-dhcp[1273]: DHCPOFFER(br0) 192.168.50.224 64:16:66:46:41:6e
Feb 20 16:41:18 dnsmasq-dhcp[1273]: DHCPREQUEST(br0) 192.168.50.224 64:16:66:46:41:6e
Feb 20 16:41:18 dnsmasq-dhcp[1273]: DHCPACK(br0) 192.168.50.224 64:16:66:46:41:6e
Feb 20 16:42:12 wlceventd: wlceventd_proc_event(491): eth6: Deauth_ind 16:91:82:0C:8B:9C, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3), rssi:0
Feb 20 16:42:12 hostapd: eth6: STA 16:91:82:0c:8b:9c IEEE 802.11: disassociated

 

[Zastoff]

As I told you before, everything is working as expected. You enabled Web & Apps Filtering, (which just like Malicious Website Blocking, will block access to certain websites), and this is what is getting logged in your system log, as access to that specified site is getting blocked.

Been using parental control/ai-protection for years over many firmware versions and never seen these in syslog until 386.5alpha1.
I am glad things get block on my kids 2 windows 10 computers and the older kids chromebook.
But would be nice if these entries got logged under trend-mirco tabs instead of syslog.
Again Thank you RMerlin !

 

[Darkje]

Guys and galls is there a way to selective stop IPv6 delagation to certain clients?

 

[JohnSmith]

Upgrade RT-AX88U & RT-AC3100 from V386.5_alpha1-gbb7ff5cb66 to V386.5_alpha2-g4fa87261ad via dirty firmware upgrade. 40+ devices (includes gaming, streaming, downloads, many IOT devices, etc.) and all appears to be working for main AX88U & backup AC3100 routers. Still postponing adding RT-AX58U with V386.4 Final into AiMesh 2.0, until Guest Network #01 issue is fixed, as Guest network is #01, and IOT devices is #02 currently in my setup.

 

[miniterror]

Installed the Alpha on my 2 AX86U's connected over the 2.5Gbit port as wired backhaul and seeying below spammed in my systemlog.
Cant remember seeying this before in there, tried to find the MAC but cant find it in my list of known devices.
Any idea what these mean?

Feb 20 23:26:21 acsd: eth6: COEX: downgraded chanspec 0x1909 to 0x100b: channel 6 used by exiting BSSs
Feb 20 22:33:55 kernel: httpd (1421): drop_caches: 1
Feb 20 23:36:12 wlceventd: wlceventd_proc_event(505): eth7: Auth 880:39:C0:60:A6, status: Successful (0)
Feb 20 23:36:12 wlceventd: wlceventd_proc_event(534): eth7: Assoc 880:39:C0:60:A6, status: Successful (0)
Feb 20 23:36:12 hostapd: eth7: STA 88:d0:39:c0:60:a6 IEEE 802.11: associated
Feb 20 23:36:16 wlceventd: wlceventd_proc_event(469): eth7: Deauth_ind 880:39:C0:60:A6, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3)
Feb 20 23:36:16 hostapd: eth7: STA 88:d0:39:c0:60:a6 IEEE 802.11: disassociated
Feb 20 23:36:17 wlceventd: wlceventd_proc_event(469): eth7: Deauth_ind 880:39:C0:60:A6, status: 0, reason: Previous authentication no longer valid (2)
Feb 20 23:36:17 hostapd: eth7: STA 88:d0:39:c0:60:a6 IEEE 802.11: disassociated

 

[gerardr]

Dirty upgrade from 386.4 to 386.5_alpha2 with RT-AX58U firmware late Friday. It's been stable for almost 48hrs now for my simple setup on an RT-AX3000. Simple setup is home-built utilities (openssh, rsync, vim, etc.) on a USB drive, running a SOCKS5 proxy server as well as a personal home page using the firmware's lighttpd with custom index.htm.

 

[unsynaps]

Man the hostapd service is log spam happy. Not sure if there is a way to turn it down or I will have to make a 'profile' for Scribe to deal with it.

 

[John_]

Been using parental control/ai-protection for years over many firmware versions and never seen these in syslog until 386.5alpha1.
I am glad things get block on my kids 2 windows 10 computers and the older kids chromebook.
But would be nice if these entries got logged under trend-mirco tabs instead of syslog.
Again Thank you RMerlin !

On the Windows systems have you tried using TCPView (from Microsoft Sysinternals) to see which program is going to that site?

 

[RMerlin]

But would be nice if these entries got logged under trend-mirco tabs instead of syslog.

The syslog entry is probably debugging output that Trend Micro left in there for when a site gets blocked.

Typically if someone is trying to access a blocked wepbage, the browser will show the router's block page informing the user. Unfortunately, doing so when accessing https sites is problematic because one of the goals behind https is to prevent these types of hijacking. This is why the final experience can be confusing when something gets blocked, as the end-user isn't notified - they simply get blocked, sometime with a browser error.

Your block is category 23, which is "Private Protocol". This blocks chat services such as Jabber or QQ, for example.

 

[Ubimo]

Every time I click on the "Adaptive QoS" button in the GUI, this is happening in syslog:

Feb 21 01:09:18 kernel: Init chrdev /dev/idp with major 190
Feb 21 01:09:18 kernel: tdts: tcp_conn_max = 8000
Feb 21 01:09:18 kernel: tdts: tcp_conn_timeout = 300 sec
Feb 21 01:09:19 kernel: SHN Release Version: 2.0.2 90120f9
Feb 21 01:09:19 kernel: UDB Core Version: 0.2.20
Feb 21 01:09:19 kernel: Init chrdev /dev/idpfw with major 191
Feb 21 01:09:20 kernel: IDPfw: flush fc
Feb 21 01:09:20 kernel: IDPfw: IDPfw is ready
Feb 21 01:09:20 kernel: sizeof forward pkt param = 280
Feb 21 01:09:20 BWDPI: fun bitmap = 3
Feb 21 01:09:29 kernel: IDPfw: Exit IDPfw
Feb 21 01:09:29 kernel: mod epilog takes 0 jiffies
Feb 21 01:09:29 kernel: IDPfw: Exit IDPfw
Feb 21 01:09:29 kernel: Exit chrdev /dev/idpfw with major 191
Feb 21 01:09:29 kernel: Exit chrdev /dev/idp with major 190
Feb 21 01:09:29 custom_config: Appending content of /jffs/configs/cake-qos.conf.add.
Feb 21 01:09:30 custom_script: Running /jffs/scripts/nat-start
Feb 21 01:09:30 custom_script: Running /jffs/scripts/firewall-start (args: ppp0)
Feb 21 01:09:54 Skynet: [*] WebUI Integration Requires Logging To Be Enabled

and

Feb 21 01:16:08 CakeQOS-Merlin: /jffs/addons/cake-qos/cake-qos (pid=9627) called in unattended mode with 1 args: startup
Feb 21 01:16:14 kernel: IDPfw: Exit IDPfw

Is this a normal bahaviour? Never noticed this before.
AC86U on latest alpha2 build.

 

[underdose]

Is this a normal bahaviour? Never noticed this before.

Similar log entries appear in the syslog when I click Adaptive QoS in the navigation.

Feb 21 16:35:34 RT-AX58U kernel: Init chrdev /dev/idp with major 190
Feb 21 16:35:34 RT-AX58U kernel: tdts: tcp_conn_max = 8000
Feb 21 16:35:34 RT-AX58U kernel: tdts: tcp_conn_timeout = 300 sec
Feb 21 16:35:39 RT-AX58U kernel: SHN Release Version: 2.0.2 d2ff630
Feb 21 16:35:39 RT-AX58U kernel: UDB Core Version: 0.2.20
Feb 21 16:35:39 RT-AX58U kernel: Init chrdev /dev/idpfw with major 191
Feb 21 16:35:39 RT-AX58U kernel: IDPfw: flush fc
Feb 21 16:35:39 RT-AX58U kernel: IDPfw: IDPfw is ready
Feb 21 16:35:39 RT-AX58U kernel: sizeof forward pkt param = 192
Feb 21 16:35:39 RT-AX58U BWDPI: fun bitmap = 3
Feb 21 16:35:48 RT-AX58U BWDPI: force to flush flowcache entries
Feb 21 16:35:48 RT-AX58U kernel: IDPfw: Exit IDPfw
Feb 21 16:35:48 RT-AX58U kernel: mod epilog takes 0 jiffies
Feb 21 16:35:48 RT-AX58U kernel: IDPfw: Exit IDPfw
Feb 21 16:35:48 RT-AX58U kernel: Exit chrdev /dev/idpfw with major 191
Feb 21 16:35:48 RT-AX58U kernel: Exit chrdev /dev/idp with major 190
Feb 21 16:35:48 RT-AX58U custom_config: Appending content of /jffs/configs/cake-qos.conf.add.
Feb 21 16:35:49 RT-AX58U custom_script: Running /jffs/scripts/firewall-start (args: eth4)
Feb 21 16:36:54 RT-AX58U (wg_firewall): 2667 Checking if WireGuard VPN Peer KILL-Switch is required.....
Feb 21 16:36:54 RT-AX58U (wg_firewall): 2667 Restarting WireGuard to reinstate RPDB/firewall rules
Feb 21 16:36:54 RT-AX58U (wg_manager.sh): 2682 v4.14 Requesting WireGuard VPN Peer stop (wg21)
Feb 21 16:36:54 RT-AX58U (wg_manager.sh): 2682 v4.14 Requesting termination of WireGuard VPN 'server' Peer ('wg21')
Feb 21 16:36:54 RT-AX58U wireguard-server: Initialising Wireguard Kernel module '/lib/modules/4.1.52/kernel/net/wireguard/wireguard.ko'
Feb 21 16:36:55 RT-AX58U wireguard-server1: Wireguard VPN 'server' Peer (wg21) on redacted.ip.address:51820 Terminated
Feb 21 16:36:55 RT-AX58U (wg_manager.sh): 2991 v4.14 Requesting WireGuard VPN Peer start ( wg21 )
Feb 21 16:36:55 RT-AX58U (wg_manager.sh): 2991 v4.14 Initialising Wireguard VPN 'server' Peer (wg21)
Feb 21 16:36:55 RT-AX58U wireguard-server: Initialising Wireguard Kernel module '/lib/modules/4.1.52/kernel/net/wireguard/wireguard.ko'
Feb 21 16:36:56 RT-AX58U wireguard-server1: Initialising Wireguard VPN 'Server' Peer (wg21) on redacted.ip.address:51820
Feb 21 16:36:56 RT-AX58U wireguard-server1: Initialisation complete.
Feb 21 16:36:56 RT-AX58U CakeQOS-Merlin: /jffs/addons/cake-qos/cake-qos (pid=3295) called in unattended mode with 1 args: startup
Feb 21 16:36:56 RT-AX58U CakeQOS-Merlin: Applying iptables rules

 

[dave14305]

Every time I click on the "Adaptive QoS" button in the GUI, this is happening in syslog:

Feb 21 01:09:18 kernel: Init chrdev /dev/idp with major 190
Feb 21 01:09:18 kernel: tdts: tcp_conn_max = 8000
Feb 21 01:09:18 kernel: tdts: tcp_conn_timeout = 300 sec
Feb 21 01:09:19 kernel: SHN Release Version: 2.0.2 90120f9
Feb 21 01:09:19 kernel: UDB Core Version: 0.2.20
Feb 21 01:09:19 kernel: Init chrdev /dev/idpfw with major 191
Feb 21 01:09:20 kernel: IDPfw: flush fc
Feb 21 01:09:20 kernel: IDPfw: IDPfw is ready
Feb 21 01:09:20 kernel: sizeof forward pkt param = 280
Feb 21 01:09:20 BWDPI: fun bitmap = 3
Feb 21 01:09:29 kernel: IDPfw: Exit IDPfw
Feb 21 01:09:29 kernel: mod epilog takes 0 jiffies
Feb 21 01:09:29 kernel: IDPfw: Exit IDPfw
Feb 21 01:09:29 kernel: Exit chrdev /dev/idpfw with major 191
Feb 21 01:09:29 kernel: Exit chrdev /dev/idp with major 190
Feb 21 01:09:29 custom_config: Appending content of /jffs/configs/cake-qos.conf.add.
Feb 21 01:09:30 custom_script: Running /jffs/scripts/nat-start
Feb 21 01:09:30 custom_script: Running /jffs/scripts/firewall-start (args: ppp0)
Feb 21 01:09:54 Skynet: [*] WebUI Integration Requires Logging To Be Enabled

and

Feb 21 01:16:08 CakeQOS-Merlin: /jffs/addons/cake-qos/cake-qos (pid=9627) called in unattended mode with 1 args: startup
Feb 21 01:16:14 kernel: IDPfw: Exit IDPfw

Is this a normal bahaviour? Never noticed this before.
AC86U on latest alpha2 build.

The Bandwidth Monitor page requires certain Trend Micro components to temporarily load in order to gather the per-device and App Analysis data. When Adaptive QoS is enabled, no extra action is required, so no log messages would appear. When it’s not enabled, it loads what it needs and forces QoS and the Firewall to restart.

 

[maxbraketorque]

Updated from alpha 1 to alpha 2 about 8 hours ago on my ax88u.
Checked log again now, I get spammed with these:

Feb 19 17:03:02 RT-AX88U-6C58 kernel: ** ERROR: [send_redir_page:625] # redir_url=https://192.168.1.1:8443/blocking.asp?cat_id=23&mac=**********23&domain=acds.prod.vidible.tv
Feb 19 17:03:03 RT-AX88U-6C58 kernel: ** ERROR: [send_redir_page:625] # redir_url=https://192.168.1.1:8443/blocking.asp?cat_id=23&mac=**********23&domain=acds.prod.vidible.tv
Feb 19 17:03:04 RT-AX88U-6C58 kernel: ** ERROR: [send_redir_page:625] # redir_url=https://192.168.1.1:8443/blocking.asp?cat_id=23&mac=**********23&domain=acds.prod.vidible.tv
Feb 19 17:03:04 RT-AX88U-6C58 kernel: ** ERROR: [send_redir_page:625] # redir_url=https://192.168.1.1:8443/blocking.asp?cat_id=23&mac=**********23&domain=acds.prod.vidible.tv
Feb 19 17:03:05 RT-AX88U-6C58 kernel: ** ERROR: [send_redir_page:625] # redir_url=https://192.168.1.1:8443/blocking.asp?cat_id=23&mac=**********23&domain=acds.prod.vidible.tv
Feb 19 17:03:07 RT-AX88U-6C58 kernel: ** ERROR: [send_redir_page:625] # redir_url=https://192.168.1.1:8443/blocking.asp?cat_id=23&mac=**********23&domain=acds.prod.vidible.tv
Feb 19 17:03:07 RT-AX88U-6C58 kernel: ** ERROR: [send_redir_page:625] # redir_url=https://192.168.1.1:8443/blocking.asp?cat_id=23&mac=**********23&domain=acds.prod.vidible.tv
Feb 19 17:03:08 RT-AX88U-6C58 kernel: ** ERROR: [send_redir_page:625] # redir_url=https://192.168.1.1:8443/blocking.asp?cat_id=23&mac=**********23&domain=acds.prod.vidible.tv
Feb 19 17:03:08 RT-AX88U-6C58 kernel: ** ERROR: [send_redir_page:625] # redir_url=https://192.168.1.1:8443/blocking.asp?cat_id=23&mac=**********23&domain=acds.prod.vidible.tv
Feb 19 17:03:09 RT-AX88U-6C58 kernel: ** ERROR: [send_redir_page:625] # redir_url=https://192.168.1.1:8443/blocking.asp?cat_id=23&mac=**********23&domain=acds.prod.vidible.tv

Was the same on alpha 1 and i did not get these on 386.4
It only happens with clients i have in DNS-Filter mostly set to use cleanbrowsing-family and NextDNS
(No one is complaining in the family so guess things work anyway on these clients but get spammed in the log..)
Did something change with DNS-Filter since 386.4?
Anyone else seen these?

I'm seeing the same thing when I upgraded from 386.4 to 386.5a2 on my AC86U. The Apple App store seems to get blocked when I enable blocking of file transfer and P2P on my daughter's iPhone, so the ASUS log quickly becomes a sea of these messages.

As I told you before, everything is working as expected. You enabled Web & Apps Filtering, (which just like Malicious Website Blocking, will block access to certain websites), and this is what is getting logged in your system log, as access to that specified site is getting blocked.

Nice to know that nothing is "broken", but these messages are spamming the hell out of my log. Never happened before, so presumably something was changed by ASUS. Hopefully they will put it back.

 

[Elmer]

AX88 (alpha2) w/ AImesh units (stock 46065): Constantly getting this error. Also, the AImesh units have very few clients (have rebooted each unit). Can someone tell me what this error is?

CFG80211-ERROR) wl_cfg80211_change_station : WLC_SCB_AUTHORIZE sta_flags_mask not set

I see past threads where they say not to worry about it. Just thought there might be a connection between the odd AImesh behavior and that error.

 

[Akore]

Running 386.5_alpha2-g4fa87261ad on RT-AC68U .... I'm getting some strange logs:

Feb 21 13:34:12 dnsmasq-dhcp[1593]: DHCPOFFER(br1) 192.168.101.11 2c:a#####
Feb 21 13:34:12 dnsmasq-dhcp[1593]: DHCPREQUEST(br1) 192.168.101.11 2c:a#####
Feb 21 13:34:12 dnsmasq-dhcp[1593]: DHCPACK(br1) 192.168.101.11 2c:a##### WyzeCam
Feb 21 13:34:12 dnsmasq-dhcp[1593]: DHCPDISCOVER(br1) 2c:a#####
Feb 21 13:34:12 dnsmasq-dhcp[1593]: DHCPOFFER(br1) 192.168.101.11 2c:a#####
Feb 21 13:34:12 dnsmasq-dhcp[1593]: DHCPREQUEST(br1) 192.168.101.11 2c:a#####
Feb 21 13:34:12 dnsmasq-dhcp[1593]: DHCPACK(br1) 192.168.101.11 2c:a##### WyzeCam
Feb 21 13:34:15 kernel: 2C:A##### not mesh client, can't delete it
Feb 21 13:34:15 kernel: 2C:A##### not mesh client, can't delete it
Feb 21 13:34:15 kernel: 2C:A##### not mesh client, can't delete it

Anyone see these before or have ideas on what the cause might be?

 

[Mister2088]

I did a dirty upgrade around 6 hours ago. For single router set up (no aimesh), all is working well so far. See my signature for my setup.

The only critique that has always been there, seemingly: when you select a firmware .w file for upgrade, it automatically starts. It would be nice in the future to have a warning dialogue something like: 'are you sure you want to apply?'

Thanks @RMerlin !

 

[octopus]

BETA relese is out:
https://www.snbforums.com/threads/asuswrt-merlin-386-5-beta-is-now-available.77544/

 

[Ellenswamy]

BETA relese is out:
https://www.snbforums.com/threads/asuswrt-merlin-386-5-beta-is-now-available.77544/

Yay! Ax11000.

 

[shabbs]

BETA relese is out:
https://www.snbforums.com/threads/asuswrt-merlin-386-5-beta-is-now-available.77544/

Let's GO!

 

[jsbeddow]

Let's GO!

I wouldn't get too overly excited: for any of us that already installed the 386.5 Alpha 2, I don't see any changes on Github in the less than 72 hours since the release of that version. Yes, support was completed for the new GT-AX11000, but if your model was already included in Alpha 2, there were no material changes (one typo in labels corrected).