Release New AC86U firmware 3.0.0.4.386_42643

[OzarkEdge]

I updated from 40451 (latest firmware without the overheat bug). Before the update, cpu temp was 86-87 celsius. After the update: 97-98 celsius... And cpu prochot - cpu core1 switch off messages started to appear in the log.

I didn't do factory reset and I won't do it (came from an fw without the bug, so this overheat issue shouldn't happen...)

Downgraded to 40451. I am happy with it.

The CPU heat issue was introduced with 41634 (after 40451), and was "fixed" prior to release of 41994 and may be improved a bit with the current 42643.

40451 AiMesh 2.0
41634 adds Fullcone NAT; disables CPU wait state (higher temp)
beta 9.0.0.4.386.41994 DNSmasq fix; enables CPU wait state (lower temp).
42634 latest greatest

I had to factory reset 41994 to get the fix... to re-enable the CPU wait state... a dirty upgrade did not do it.

Your choices appear to be... stick with AiMesh 2.0 introduction firmware, or install and reset current firmware 42634 and configure it from scratch. (Run SSH command pwr show to confirm CPU wait is enabled. If not, reset the firmware and configure from scratch.)

Some suggested reading:

Reset FAQ
Reset Button/webUI Restore
WPS Button Hard Reset

OE

 

[geriguy]

The CPU heat issue was introduced with 41634 (after 40451), and was "fixed" prior to release of 41994 and may be improved a bit with the current 42643.

40451 AiMesh 2.0
41634 adds Fullcone NAT; disables CPU wait state (higher temp)
beta 9.0.0.4.386.41994 DNSmasq fix; enables CPU wait state (lower temp).
42634 latest greatest

I had to factory reset 41994 to get the fix... to re-enable the CPU wait state... a dirty upgrade did not do it.

Your choices appear to be... stick with AiMesh 2.0 introduction firmware, or install and reset current firmware 42634 and configure it from scratch. (Run SSH command pwr show to confirm CPU wait is enabled. If not, reset the firmware and configure from scratch.)

Some suggested reading:

Reset FAQ
Reset Button/webUI Restore
WPS Button Hard Reset

OE

Strange because I came from 40451 - so I missed the hightemp fw and also the beta one and still the latest fw booted up with cpu wait disabled. As soon as I went back - without factory reset - to 40451 it was on again.

What do you think, how many percent of the users will do the hard reset? I believe you that it is needed to do just don't want to accept it. Setting up everything will take 2 hours for me. I will do it but IT CAN'T BE PART OF A NORMAL UPGRADE PROCESS.

I started to receive cpu hightemp alerts in 2 minutes. (1 main ac86u, 2 ac86u nodes, around 50 connected device.)

 

[OzarkEdge]

Strange because I came from 40451 - so I missed the hightemp fw and also the beta one and still the latest fw booted up with cpu wait disabled. As soon as I went back - without factory reset - to 40451 it was on again.

What do you think, how many percent of the users will do the hard reset? I believe you that it is needed to do just don't want to accept it. Setting up everything will take 2 hours for me. I will do it but IT CAN'T BE PART OF A NORMAL UPGRADE PROCESS.

I started to receive cpu hightemp alerts in 2 minutes. (1 main ac86u, 2 ac86u nodes, around 50 connected device.)

My normal upgrade process since the introduction of AiMesh rolling development is to reset the firmware and configure from scratch.

If you install the fixed firmware 41994 or later and the SSH command pwr show still shows the CPU wait state disabled, then a reset is required to enable the CPU wait state... I had to do this.

OE

 

[ForkWNY]

Flashed to 42643 from beta 9.0.0.4.386.41994. CPU_WAIT was enabled after a "dirty flash", so I didn't run a factory reset. I did run a factory reset when I installed 9.0.0.4.386.41994 however because CPU_WAIT was disabled. 86U seems to run fine (AiMesh node).

 

[keefrto]

Flashed to 42643 from beta 9.0.0.4.386.41994. CPU_WAIT was enabled after a "dirty flash", so I didn't run a factory reset. I did run a factory reset when I installed 9.0.0.4.386.41994 however because CPU_WAIT was disabled. 86U seems to run fine (AiMesh node).

Any issues like the 2.4 having channel 1 and another channel?

 

[bitsbytes]

can anyone try blocking internet access from the gui. when I turn it on there is no indication that it's actually on and if I go back it shows that it's off. it works but the gui is bugged which makes it very difficlut to know if it is on or off.

 

[RSengine]

Something is wrong with this firmware's WAN DNS treatment for pi-hole setups (edit - nothing is wrong. I pulled a brainfart, see replies below). When I set DNS Server1 and DNS Server2 as my pi-hole's internal IP, the internet breaks and refuses to connect.

Facts
1. The pi-hole itself had no issues prior to firmware update. Prior to firmware update (running 3.0.0.4.386.41634), I was able to point my router to pi-hole internal IP as the DNS server 1 and 2
2. The pi-hole is updated to the latest version
3. If I directly point my computer or my phone from client settings to use the pi-hole DNS server IP, it works and the computer and phone are able to access internet with adblocking enabled
4. The ASUS firmware has no problem using OpenDNS or Cloudflare external IPs as an DNS server if I choose those from router settings

My pi-hole setup
1. Pi-hole is connected to router via ethernet
2. Pi-hole uses DNS over HTTPS using the instructions from https://docs.pi-hole.net/guides/dns/cloudflared/

These facts lead me to believe that the ASUS firmware has a problem with using internal IPs as DNS servers

Any suggestions? I'd rather not do a hard reset on the router and have to manually set up settings. I have too many things (client names and rules) that I do not want to reenter everytime I update.

 

[bbunge]

Something is wrong with this firmware's WAN DNS treatment for pi-hole setups. When I set DNS Server1 and DNS Server2 as my pi-hole's internal IP, the internet breaks and refuses to connect.

Facts
1. The pi-hole itself had no issues prior to firmware update. Prior to firmware update (running 3.0.0.4.386.41634), I was able to point my router to pi-hole internal IP as the DNS server 1 and 2
2. The pi-hole is updated to the latest version
3. If I directly point my computer or my phone from client settings to use the pi-hole DNS server IP, it works and the computer and phone are able to access internet with adblocking enabled
4. The ASUS firmware has no problem using OpenDNS or Cloudflare external IPs as an DNS server if I choose those from router settings

My pi-hole setup
1. Pi-hole is connected to router via ethernet
2. Pi-hole uses DNS over HTTPS using the instructions from https://docs.pi-hole.net/guides/dns/cloudflared/

These facts lead me to believe that the ASUS firmware has a problem with using internal IPs as DNS servers

Any suggestions? I'd rather not do a hard reset on the router and have to manually set up settings. I have too many things (client names and rules) that I do not want to reenter everytime I update.

Well, I clicked the Like button and did not mean to.
The DNS Server 1 and 2 in the WAN settings need to be to an upstream resolver. Not to a Pi on the LAN. Without this your router will not get time sync when it boots. The place for your Pi-Hole LAN address is in LAN/DHCP Server/DNS Server. With this your clients will get the Pi-Hole as the first DNS server and the router for the second.
If your goal is to block adds just set the DNS Server1 and 2 to AdGuard. The router will not be used unless the Pi-Hole is down as the clients will almost always use the first DNS server first and the second as a fall back.
Nothing wrong with this firmware. Working as intended!

 

[Tech9]

Well, I clicked the Like button and did not mean to.

Click it again.

 

[RSengine]

Well, I clicked the Like button and did not mean to.
The DNS Server 1 and 2 in the WAN settings need to be to an upstream resolver. Not to a Pi on the LAN. Without this your router will not get time sync when it boots. The place for your Pi-Hole LAN address is in LAN/DHCP Server/DNS Server. With this your clients will get the Pi-Hole as the first DNS server and the router for the second.
If your goal is to block adds just set the DNS Server1 and 2 to AdGuard. The router will not be used unless the Pi-Hole is down as the clients will almost always use the first DNS server first and the second as a fall back.
Nothing wrong with this firmware. Working as intended!

Well, I feel like an idiot now. Thank you for explaining that! Setting my pihole LAN address as the LAN DNS worked.

I do have a new issue though (edit - solution found, see below). I also have OpenVPN set up from the ASUS router. When I connect to OpenVPN, my phone's DNS traffic is not being routed to the pihole DNS. It used to be able to do so when I set the WAN DNS as my pihole's internal IP

My OpenVPN settings
Respond to DNS - Yes
Advertise DNS to clients - Yes

Phone OpenVPN app does not have DNS fallback turned on

Any way to force OpenVPN clients to use the pihole?

Edit - I found a solution. I added the line "dhcp-option DNS xxx.xxx.xxx.xxx" and it now forces all DNS traffic to the pi-hole. I also turned Advertise DNS to clients to "No" because otherwise it adds the router as a DNS server, which directs it to the WAN DNS servers.

 

[hpsims]

Well, I feel like an idiot now. Thank you for explaining that! Setting my pihole LAN address as the LAN DNS worked.

I do have a new issue though (edit - solution found, see below). I also have OpenVPN set up from the ASUS router. When I connect to OpenVPN, my phone's DNS traffic is not being routed to the pihole DNS. It used to be able to do so when I set the WAN DNS as my pihole's internal IP

My OpenVPN settings
Respond to DNS - Yes
Advertise DNS to clients - Yes

Phone OpenVPN app does not have DNS fallback turned on

Any way to force OpenVPN clients to use the pihole?

Edit - I found a solution. I added the line "dhcp-option DNS xxx.xxx.xxx.xxx" and it now forces all DNS traffic to the pi-hole. I also turned Advertise DNS to clients to "No" because otherwise it adds the router as a DNS server, which directs it to the WAN DNS servers.

I think I have the same issue as you presented earlier. I have the ROG GT-2900 and when updating the firmware I get no internet. I had to downgrade to get internet to work. I suspect my Pi-hole is the issue now after reading your post. I have my Pi DNS written in both the WAN (server 1 and 2 ) and LAN ( dns dhcp server). I’m confused now at how to configure this with Pi-hole.

 

[RSengine]

I think I have the same issue as you presented earlier. I have the ROG GT-2900 and when updating the firmware I get no internet. I had to downgrade to get internet to work. I suspect my Pi-hole is the issue now after reading your post. I have my Pi DNS written in both the WAN (server 1 and 2 ) and LAN ( dns dhcp server). I’m confused now at how to configure this with Pi-hole.

I set my WAN DNS as 1.0.0.1 and 1.1.1.1. I didn't realize those HAVE to be external. In the past, the firmware for some reason allowed internal IPs for those fields, but it seems the proper way to think of those is external IPs only.

So for your situation, change the WAN DNS's to external IPs (pick 2 out of the list that you're comfortable with) and set the LAN DNS to the pi hole. Should work then.

 

[bbunge]

I think I have the same issue as you presented earlier. I have the ROG GT-2900 and when updating the firmware I get no internet. I had to downgrade to get internet to work. I suspect my Pi-hole is the issue now after reading your post. I have my Pi DNS written in both the WAN (server 1 and 2 ) and LAN ( dns dhcp server). I’m confused now at how to configure this with Pi-hole.

Get the pi hole out of the WAN settings!

 

[hpsims]

Get the pi hole out of the WAN settings!

Ok. I’ll do that and then upgrade and let you know if it fixed. Thanks

 

[dave14305]

I think I have the same issue as you presented earlier. I have the ROG GT-2900 and when updating the firmware I get no internet. I had to downgrade to get internet to work. I suspect my Pi-hole is the issue now after reading your post. I have my Pi DNS written in both the WAN (server 1 and 2 ) and LAN ( dns dhcp server). I’m confused now at how to configure this with Pi-hole.

ASUS changed the firmware to add special routing for the WAN DNS servers to ensure they get directed out the WAN interface. It would certainly break the internet if the router tries to direct traffic meant for a LAN device (like Pi-Hole) out to the internet where it could never be answered.

This was a problem in Merlin's recent firmware, but he removed this feature since it caused more issues than it solved.

But yes, the intention is that the WAN DNS servers should be out on the Internet. Clever Pi-Hole configurations will need to be rethought.

 

[hpsims]

ASUS changed the firmware to add special routing for the WAN DNS servers to ensure they get directed out the WAN interface. It would certainly break the internet if the router tries to direct traffic meant for a LAN device (like Pi-Hole) out to the internet where it could never be answered.

This was a problem in Merlin's recent firmware, but he removed this feature since it caused more issues than it solved.

But yes, the intention is that the WAN DNS servers should be out on the Internet. Clever Pi-Hole configurations will need to be rethought.

Ok. So I removed pihole out of WAN and was able to upgrade to latest firmware without issues. So thank you very much. I guess I had Pi-hole configured all wrong these last few years. I’m hoping everything still gets directed though Pi without issues. I also managed to use conditional forwarding as well after looking up more threads on configuring pi with assus router. Finally get to know what the client IP addresses refer to. Thanks again!

 

[dave14305]

I guess I had Pi-hole configured all wrong these last few years.

It was a perfectly acceptable solution until these later firmware releases introduced the routing problem.

 

[Tech9]

Asus had to mention the change somewhere @dave14305. Regular users have no way to find out what the problem is.

 

[hpsims]

It was a perfectly acceptable solution until these later firmware releases introduced the routing problem.

Very true.

 

[dave14305]

Asus had to mention the change somewhere @dave14305. Regular users have no way to find out what the problem is.

"Had to" or "should have"? I agree it's befuddling to regular users, but it came around the 42095 versions and isn't mentioned in the release notes that I have seen.