What's new

Release Asuswrt-Merlin 386.4 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!

Status
Not open for further replies.
Just installed 386.4 and did a factory reset. Everything seems to be running okay except one issue. In adaptive QOS, I enabled cake but can't see the tab for Cake QOS. Has this been removed?

Previously in 386.3_2 I remember there being a Cake QOS tab?
 
Many thanks. It seems the NVRAM values were the clue.
Did you initially set them to Google over SSH, or through the webui?
 
It looks like you have activated the "Captcha login" under the advanced manage content menu (system). Just below the user and password login setup ... you can disable this option.
You're right, it was enabled but that's not the problem, disabled it but still the same thing.

Found out it's forcing HTTPS because I'm using the Asus mobile app as well so now instead of just typing 192.168.50.1 into my web browser I need to type https://192.168.50.1:8443 and it works fine. Odd that this only started from 386.4 but at least it works now
 
Seeing this error in the new firmware
Jan 2 16:05:58 kernel: ERROR [sysport_classifier_flow_port_add,739]: Egress port 1 is already in use
Jan 2 16:05:58 kernel: ^[[0;33;41m[ERROR archer] archer_mcast_activate,569: ADD_PORT: Could not sysport_classifier_flow_port_add^[[0m

Also getting a lot of eth5 auth assoc and deauth_index every few minutes.
 
Interestingly. On my AC86U . The dns_probe_content is *
That is not the default value, something must have changed this at some point.
Idk what this would do when the ISP's DNS goes out tho
If the ISP DNS is down, then you most likely have a problem anyway, unless you were overriding the ISP DNS. Full ISP DNS outage is very rare however, assuming they properly implemented redundancy, and didn't have both DNS IPs point at the same physical DNS server... I would expect them to resolve these types of issues very quickly anyway, so your router will only report the connection being down for that period of time.

I just upgraded my RT-AX56U from 386.3_2 to 386.4 and now I cannot log into my router via the web interface. "Invalid user name or password." I've cleared my browser cache and rebooted the router. I've also tried the factory default credentials with no luck. Any other ideas before I factory reset?
If you had enabled SSH then try accessing over SSH.
Anyone getting this now when logging into the webUI? Comes up every time and has only started since 386.4, any ideas of how to stop it from coming up?
It's a new feature Asus recently added to encourage people to use https instead of http for security reasons. Quite bluntly, blame it on "security experts" who open CVE issues whenever a router defaults to http, leading to manufacturers implementing these kind of "security enhancements". I haven't studied Asus' implementation, but it's possible that if you set your router to HTTP-only instead of HTTP+HTTPS, it might go away. Otherwise, start using https when accessing your router.

In adaptive QOS, I enabled cake but can't see the tab for Cake QOS. Has this been removed?
Cake is a QoS mode of its own, it was never supported by Adaptive QoS. If you are thinking of fq_codel, that was removed last year because it was no longer possible to hack fq_codel on top of Adaptive QoS due to changes Trend Micro did on their end.
 
Known issue generally caused by pixelserv-tls (or any other addon that adds a custom network interface), which causes the TrendMicro dcd daemon to crash. Nothing I can do about it, you will have to uninstall pixelserv-tls.

I am also getting this error. Can I safely ignore it, or should I disable Trend or Diversion or both?
Trying the ASUS Firmware followed by the latest Merlin did not solve this issue (as it did for another user on here)
 
I am also getting this error. Can I safely ignore it, or should I disable Trend or Diversion or both?
You can still use Diversion, you just need to disable pixelsrv-tls.

I don't know what kind of impact these crashing dcd process can have on router performance or whether it will affect any of the Trend Micro-related features.
 
You can still use Diversion, you just need to disable pixelsrv-tls.

I don't know what kind of impact these crashing dcd process can have on router performance or whether it will affect any of the Trend Micro-related features.
Not sure if you saw the error I posted above
 
Not sure if you saw the error I posted above
Related to Broadcom components. No idea what they mean, and outside of my control.
 
It's a new feature Asus recently added to encourage people to use https instead of http for security reasons. Quite bluntly, blame it on "security experts" who open CVE issues whenever a router defaults to http, leading to manufacturers implementing these kind of "security enhancements". I haven't studied Asus' implementation, but it's possible that if you set your router to HTTP-only instead of HTTP+HTTPS, it might go away. Otherwise, start using https when accessing your router.
That's exactly what it was mate, I'll just use HTTPS from now on as I use the mobile app too which requires it to be enabled.

Thanks to everyone for their help!
 
Dirty upgrade from 386.3.2 to 386.4 AX86U and AX58U node. Everything went flawlessly, things seem a little snappier on my network. Thanks for the upgrade Merlin!
 
That is not the default value, something must have changed this at some point.

If the ISP DNS is down, then you most likely have a problem anyway, unless you were overriding the ISP DNS. Full ISP DNS outage is very rare however, assuming they properly implemented redundancy, and didn't have both DNS IPs point at the same physical DNS server... I would expect them to resolve these types of issues very quickly anyway, so your router will only report the connection being down for that period of time.


If you had enabled SSH then try accessing over SSH.

It's a new feature Asus recently added to encourage people to use https instead of http for security reasons. Quite bluntly, blame it on "security experts" who open CVE issues whenever a router defaults to http, leading to manufacturers implementing these kind of "security enhancements". I haven't studied Asus' implementation, but it's possible that if you set your router to HTTP-only instead of HTTP+HTTPS, it might go away. Otherwise, start using https when accessing your router.


Cake is a QoS mode of its own, it was never supported by Adaptive QoS. If you are thinking of fq_codel, that was removed last year because it was no longer possible to hack fq_codel on top of Adaptive QoS due to changes Trend Micro did on their end.

Thank you for the quick response. I figured out the problem. The Cake-QOS tab was a separate script I had to install. For some reason I thought it was included by default now. I've installed the script and now the tab is back.

This leads me to ask if I didn't install the script, I assume cake would still be running on the vanilla 386.4 install as long as the option was ticked?

Great work RMerlin. Appreciate all your efforts.
 
Did you initially set them to Google over SSH, or through the webui?
I don’t remember to have changed the dns_probe_content and the dns_probe_host in order to point to Google. I am quite sure I didn’t do it through SSH (at least not consciously) and now I have just been looking for this option under the WebUi but I didn’t find where it is located.

I have been using manual DNS, under WAN menu, pointing to 1.1.1.1 & 1.0.0.1 for at least a couple of years. Only just at the beginning my DNS were pointing to Google.

Maybe an old script did the mess. I don’t know.

Thank you for your quick assistance in order to solve the issue.
 
Dirty upgrade on my AC86 with 386.3_2 to 386.4. No issues everything working as expected.

One thing I keep hoping for with every upgrade is that an issue with WiFi radar would be resolved.

I use WiFi Radar to check which channels my neighbors are running their APs on so if necessary I can switch the channels I am using. What happens is that after I switch the channel on my AP, the WiFi Radar doesn't show the change. It continues to show the AP on the channel it originally saw the AP's SSID on. Starting stopping WiFi Radar, changing WiFi Radars settings, restarting the WiFi on the AC86 doesn't fix the issue. The only thing that works is to reboot the router.

Probably not something that can be fixed by Merlin as ASUS probably has the code in one of their locked blobs.

Many thanks to Merlin and a very Happy New Year to him!
 
I need to figure out how to fix the “disconnected” but connected bug…it prevents Alexa from working on the app as the app thinks it is disconnected. ISP is GVTC & has configured their network as a STEM if I have the term right…no public IP, etc.
Telus does this too. They CGNAT a lot of their residential customers. If you don't need port forwarding, they just stick you on a shared ip. WhatIsMyIP will say that you're on 207.xxx.xxx.xxx, but the router will pull a 100.80.xxx.xxx IP from a bridged modem. They typically do this because of how inefficient they are with IPs - the Modem gets an IP, your router gets an IP, Optik TV devices get IPs - they're handing out 4+ to a lot of customers. They finally had to do something to reign that in a bit. People have posted on forums that they can plug a bunch of routers into Port 1 through a switch and they all get unique IPs. I know one person with a four-plex that did that and had ethernet going to each separate unit... likely 9+ IPs handed out for one account. (This is against their TOS, btw.)

Anyway, CGNAT was born, and gamers and VOIP users everywhere shook their fists at the ISP gods. "How could you make our jobs more challenging!? Nooo!..."

Though truthfully, unless you're port forwarding and running servers, it works pretty seamlessly.
If the ISP DNS is down, then you most likely have a problem anyway, unless you were overriding the ISP DNS. Full ISP DNS outage is very rare however, assuming they properly implemented redundancy, and didn't have both DNS IPs point at the same physical DNS server... I would expect them to resolve these types of issues very quickly anyway, so your router will only report the connection being down for that period of time.
Yeah, ISP DNS only goes down once every month or two here. Very rare. (I use CloudFlare + Google for this reason.) Our ISPs are brilliant in Canada.

It's a new feature Asus recently added to encourage people to use https instead of http for security reasons. Quite bluntly, blame it on "security experts" who open CVE issues whenever a router defaults to http, leading to manufacturers implementing these kind of "security enhancements". I haven't studied Asus' implementation, but it's possible that if you set your router to HTTP-only instead of HTTP+HTTPS, it might go away. Otherwise, start using https when accessing your router.


Cake is a QoS mode of its own, it was never supported by Adaptive QoS. If you are thinking of fq_codel, that was removed last year because it was no longer possible to hack fq_codel on top of Adaptive QoS due to changes Trend Micro did on their end.
Thanks, good to know. :)
 
Installed over latest stock onto ax88u >6 hours ago. My somewhat vanilla setup is running well so far. Thanks Merlin!
The only two things noticed, versus stock:
1. Https certificate seems not supported for merlin? If not no biggie as self cert is ok, just annoying pop up message
2. Seems like Firefox works best for gui. Ms edge and Chrome seems to not display properly for pages like admin wireless log.
Meanwhile, stock displayed well in all 3. No biggie as Firefox works well, as mentioned.
 
Https certificate seems not supported for merlin?
They are, same as stock firmware.

Seems like Firefox works best for gui. Ms edge and Chrome seems to not display properly for pages like admin wireless log.
No issue with Chrome here, try clearing your cache (Asuswrt-Merlin's wireless log page is completely different from stock), and check for conflicting addons.
 
1641162693023.png


Load average is high - no ?
 
Dirty upgrade from 386.3_2 to 386.4_0 and I am getting the same "WAN disconnected" issue of other users. The output of the commands requested to them is:

Code:
ASUSWRT-Merlin RT-AX86U 386.4_0 Sat Jan  1 18:42:21 UTC 2022

# nslookup dns.msftncsi.com
Server:    1.1.1.1
Address 1: 1.1.1.1 one.one.one.one

Name:      dns.msftncsi.com
Address 1: 131.107.255.255 dns.msftncsi.com
Address 2: fd3e:4f5a:5b81::1

# nvram get dns_probe_host
dns.msftncsi.com
# nvram get dns_probe_content
131.107.255.255 112.4.20.71 fd3e:4f5a:5b81::1

I never touched that configuration and reading the thread I am not sure how to fix it, as they seem to be correct:
The way WAN monitoring works is a bit similar to how Windows itself does. The router will try to resolve the hostname found in dns_probe_host, and make sure it matches one of the addresses found in dns_probe_content.

Any hint about how to solve this?

EDIT: I think I got what triggers the issue in my case. If I configure DNS like this:

1641167453066.png


It is not working as shown before. If I set it to yes, WAN presence is correctly recognized. The output of the commans in this case is similar:

Code:
# nslookup dns.msftncsi.com
Server:    85.38.28.7
Address 1: 85.38.28.7 dns-alice-7.interbusiness.it

Name:      dns.msftncsi.com
Address 1: 131.107.255.255 dns.msftncsi.com
Address 2: fd3e:4f5a:5b81::1

# nvram get dns_probe_host
dns.msftncsi.com
# nvram get dns_probe_content
131.107.255.255 112.4.20.71 fd3e:4f5a:5b81::1

Note that I have DNSSEC configured as well, I am not sure if this influences the result, but in any case this is my full DNS configuration:

1641167603810.png


EDIT2: also disabling all the DNS security options will leave the WAN in disconnect state. Only selecting "YES" to "Connect to DNS Server automatically" makes it work.

EDIT3: I noticed by the nslookup command that the reply from 1.1.1.1 for some reason was very slow. Specifying 8.8.8.8 as custom DNS the reply is fast and the WAN is correctly detected. So it is definitively a timing issue. Not sure why 1.1.1.1 is so slow in my case.
 
Last edited:
Status
Not open for further replies.

Latest threads

Sign Up For SNBForums Daily Digest

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