Release Asuswrt-Merlin 3006.102.4 is now available

[jimf]

Reserved post.

Downloaded this release to my XT12. All went well except one thing (which I presume isn't really supported yet). If I toggle off Set AP Isolated on a guest network, it works but it won't work on devices that need the satellite router. If I try to bind that device to the satellite, the UI says it works but my Roku TV just won't connect. Fix is to turn Set AP Blocked back on, unbind the TV, then reboot the satellite router. Use case for this is that my TVs are on a guest network to protect my primary network and I want to use screen mirroring (I don't care if my iOT stuff wants to hack each other . Again, this works so long as a satellite router is not involved.

Very nice release, looking forward to the fixes.

Jim

 

[Natty]

Reboot scheduler stopped performing the scheduled nightly reboot 3 days ago. It had been working reliably and rebooting each night for the past few weeks since installing 3006.102.4 No users are complaining about network access. Everything else seems to be working as before. I will power cycle, then check in the morning to see if that fixed it.

This is the end of the last info in the syslog:

Jan  1 00:00:50 kernel: ----------------------- BPM Status --------------------------
Jan  1 00:00:50 kernel: tot_buf                 = 33296
Jan  1 00:00:50 kernel: avail                   = 528
Jan  1 00:00:50 kernel: cur                     = 32768
Jan  1 00:00:50 kernel: no_buf_err              = 0
Jan  1 00:00:50 kernel: cum_alloc               = 32768
Jan  1 00:00:50 kernel: cum_free                = 0
Jan  1 00:00:50 kernel: min_availability        = 496
Jan  1 00:00:50 kernel: max_watermark           = 33328
Jan  1 00:00:50 kernel: buf_expansion_count     = 173
Jan  1 00:00:50 kernel: buf_shrink_count        = 1
Jan  1 00:00:50 kernel: buf_exp_fail_count      = 0
Jan  1 00:00:50 kernel: buf_inthr_alloc_count   = 0
Jan  1 00:00:50 kernel: skb_inthr_alloc_count   = 0
Jan  1 00:00:50 kernel: max_dyn                 = 55924
Jan  1 00:00:50 kernel: tot_resv_buf            = 0
Jan  1 00:00:50 kernel: rxbds                   = 0
Jan  1 00:00:50 kernel: -------------------------------------------------------------
Jan  1 00:00:50 kernel: BPM Skbuff Pool: avail 11184 total 11184 bound 55924
Jan  1 00:00:51 kernel: tfat: loading out-of-tree module taints kernel.
Jan  1 00:00:54 kernel: MACSEC: macsec is not enabled
Jan  1 00:00:55 kernel: eth0 (Int switch port: 5) (Logical Port: 5) (phyId: 11) Link Up at 2500 mbps full duplex
Jun 15 04:12:42 crond[3134]: time disparity of 764831 minutes detected

If there are any clues to look for in the hundreds of logged lines on each reboot, let me know.

 

[Natty]

Did I just encounter a "well known bug" with scheduling in Administration? That would be a "bug" that I never encountered previously with RT-AC66U_B1 running 386.14.2 and scheduled to make the same nightly reboot, which worked reliably for many years.

 

[ColinTaylor]

Did I just encounter a "well known bug" with scheduling in Administration? That would be a "bug" that I never encountered previously with RT-AC66U_B1 running 386.14.2 and scheduled to make the same nightly reboot, which worked reliably for many years.

I don't think so. IIRC that "bug" only effected the RT-AC86U and it resulted in the router being powered off. That's not the same symptom that you're reporting.

 

[RMerlin]

102_36957 (which will be used for the next Wifi 6 release) contains a number of changes related to the Reboot Scheduler.

 

[Natty]

Power cycling brought the Reboot Scheduler back to a working state (though I need't have bothered as an hour later a few short power cuts did the job all over again). Looking forward to 102_36957 - thanks @RMerlin

 

[redbird71]

If got two AX86U Pro currently on 3006.102.4. Very clean install. Both routers have trouble with 2 specific devices connected to an IOT guest network. They will work for a time, than loose conection. To bring them back online I have to deactivate the 2.4GHz radio in the profesional tab - apply - activate - apply, or restart the router.

Is this a known problem? Are there any workarrounds so I don't have to manually do this?

 

[rung]

If got two AX86U Pro currently on 3006.102.4. Very clean install. Both routers have trouble with 2 specific devices connected to an IOT guest network. They will work for a time, than loose conection. To bring them back online I have to deactivate the 2.4GHz radio in the profesional tab - apply - activate - apply, or restart the router.

Is this a known problem? Are there any workarrounds so I don't have to manually do this?

For some of us, yes. This worked for me:
Link

 

[RMerlin]

@RMerlin I encountered an issue with DNS Director IPv6 today after rebooting the router after a factory reset and reconfigure. The DNSFILTER chain for ip6tables did not include the default DNAT statement, and I assume it was due to a race condition with the population of the router's IPv6 address on startup. This was the state of the generated rules:

# cat nat_rules_ipv6.dnsfilter
*nat
:DNSFILTER - [0:0]
-A PREROUTING -i br+ -p udp -m udp --dport 53 -j DNSFILTER
-A PREROUTING -i br+ -p tcp -m tcp --dport 53 -j DNSFILTER
-A DNSFILTER -m mac --mac-source 4C:03:xx:xx:xx:xx -j RETURN
COMMIT

I restarted dnsfilter and it came back as expected:

# service restart_dnsfilter
# cat nat_rules_ipv6.dnsfilter
*nat
:DNSFILTER - [0:0]
-A PREROUTING -i br+ -p udp -m udp --dport 53 -j DNSFILTER
-A PREROUTING -i br+ -p tcp -m tcp --dport 53 -j DNSFILTER
-A DNSFILTER -m mac --mac-source 4C:03:xx:xx:xx:xx -j RETURN
-A DNSFILTER -j DNAT --to-destination [2601:dead:beef:cafe::1]
COMMIT

And I assume this is because nvram variable ipv6_rtr_addr was still empty when dnsfilter last "started". So this could be an argument to use the REDIRECT target for IPv6 as well, or include another restart of dnsfilter when IPv6 is bound.

Unable to reproduce here, but since there are bazillions of different IPv6 implementations, it might be ISP-specific.

REDIRECT: not an option, that target does not exist for IPv6 in the iptables version used by Asuswrt.
Restarting the firewall on bound6(): would be too disruptive to the whole network in case you have an ISP that regularly gives you a new WAN IPv6.

I tried to reapply only the DNSFilter portion, gave up since part of the rules are handled by the main firewall code, so they must be done at the same time the rest of the table gets flushed.

Unless others can confirm that this is a common issue, and someone can come up with some way to resolve this without making major changes to the whole implementation, this will have to remain as-it.

 

[RMerlin]

On my AX88U Pro with that firmware OpenVPN / Client will use VPN to access internet only does no longer work.
All clients can also access the VPN server side LAN IPs.

@RMerlin

It's a bug caused by the (half-implemented) support for OpenVPN servers with SDNs. Should be fixed in 3006.102.5.

In the meantime, you can flush the stray firewall rules that are causing the bypass:

service stop_vpnserver1
iptables -F OVPNSF
service start_vpnserver1

 

[dave14305]

Unless others can confirm that this is a common issue, and someone can come up with some way to resolve this without making major changes to the whole implementation, this will have to remain as-it.

Your reply reminded me to check this since I had just swapped routers yesterday, and sure enough, the DNSFILTER chain was incomplete, as originally reported. This was on a cold boot while also waiting for the cable modem to initialize (on Comcast/Xfinity).

I’ve seen other router platforms recommend using loopback IPs for the redirect, but that doesn’t seem to work on our Linux in some quick tests.

 

[redbird71]

For some of us, yes. This worked for me:
Link

Maybe it's too early for celebrations, but deactivating Smart Connect and using WPA2-Personal (only) on the 2.4GHz network, seams to have done the trick. Thanks.

 

[dcjarvis]

There's a bug (I think carried over from ASUS firmware) that affects AI nodes. The 5Ghz band duplicates the 2.4Ghz band SSID on the node, instead of using the same SSID on for 5Ghz on the main router.

 

[Dedel66]

@dcjarvis
Please add a profile with the model and setup so everyone can see what you're referring to.

I can't confirm this bug, neither in the 104 nor in the 105 alpha1 version.
I have two different WLANs here in 5GHz and 2.4 GHz with different names, which were correctly adopted by the node.
The guest network and IOT network are also correctly configured in the node.

 

[dcjarvis]

There's a bug (I think carried over from ASUS firmware) that affects AI nodes. The 5Ghz band duplicates the 2.4Ghz band SSID on the node, instead of using the same SSID on for 5Ghz on the main router.

GT-AXE16000 as main router. Merlin 3006.102.4.

I have another ASUS router (RT-AX88U PRO) set as the mesh node. All was good under the prior firmware (Merlin 3004.388.8_4).

But under 3006, the SSID on the mesh node for both the 2.4GHz and 5 GHx band are the same. That is, should be ASUS10 and ASUS10_5G respectively (and that's what it is on the main router), but instead both SSIDs on the mesh nose are set to ASUS10. I can see this in the Fronthaul information under the AIMesh-->Network tab for the mesh node.

 

[bennor]

GT-AXE16000 as main router. Merlin 3006.102.4.

What are the AiMesh node routers and what firmware are each of them running?
May help if you post some screenshots of your AIMesh settings and WiFi settings so others can review.
PS: As a troubleshooting step have you tried deleting the AiMesh nodes, rebooting the main router, then readding the AiMesh nodes to see if the issue persists?
And something to be aware of from the Change Log for 3006.102.x Asus-Merlin firmware:

- NOTE: The new GPL codebase changed the way wireless networks
are configured. If you ever revert to an older
firmware, you MUST do a factory default reset following
the firmware downgrade, on both the router and any
existing AiMesh nodes.

 

[dcjarvis]

What are the AiMesh node routers and what firmware are each of them running?
May help if you post some screenshots of your AIMesh settings and WiFi settings so others can review.
PS: As a troubleshooting step have you tried deleting the AiMesh nodes, rebooting the main router, then readding the AiMesh nodes to see if the issue persists?
And something to be aware of from the Change Log for 3006.102.x Asus-Merlin firmware:

I appreciate your help. I posted more details about my system above (we were apparently posting at the same time), but because others have posted about this same issue with the AXE16000, I'm fairly convinced it's a software issue. https://www.snbforums.com/threads/aimesh-node-receiving-same-ssid-on-both-bands.94522/#post-959877

I did all the troubleshooting you mention, including hard system resets of the router and mesh node, and deleting and re-adding the mesh node.

None of it solved my issue. Downgrading the AXE16000 to the 3004 codebase did work. So I think it's a bug.

(I didn't save any screenshots unfortunately.)

 

[rickysuperdog]

GT-AXE16000 as main router. Merlin 3006.102.4.

I have another ASUS router (RT-AX88U PRO) set as the mesh node. All was good under the prior firmware (Merlin 3004.388.8_4).

But under 3006, the SSID on the mesh node for both the 2.4GHz and 5 GHx band are the same. That is, should be ASUS10 and ASUS10_5G respectively (and that's what it is on the main router), but instead both SSIDs on the mesh nose are set to ASUS10. I can see this in the Fronthaul information under the AIMesh-->Network tab for the mesh node.

Have you enabled Smart Connect? I found that this feature had many issues and I had disable it long time ago.

 

[casao94]

Has the issue been fixed already where if you set and SAVE the SDN (VLAN) Profile from VLAN Switch Control Settings, the will go back to the first entry in the SDN (VLAN) Profile drop down list regardless of the one you have selected?
I have this issue on 3006.102.4 on RT-BE96U

 

[Dedel66]

Edit: deleted cause answered in wrong thread
SORRY