Beta Asuswrt-Merlin 3006.102.4 Beta is now available

[rung]

I did want to add that I really appreciate having the ability to easily isolate my wired voip box with this latest Merlin beta. Before it took three configuration scripts (firewall, dnsmasq, and services) and now I just had to go to lan, vlan, set the port to access, and select my guest network. Done!

 

[alekc_oc]

This setting now is in the Professional section of Wireless settings 5GHz.

Sorry for the erroneous information, after double-checking I verified that this setting is in the wireless section.

 

[visortgw]

I did want to add that I really appreciate having the ability to easily isolate my wired voip box with this latest Merlin beta. Before it took three configuration scripts (firewall, dnsmasq, and services) and now I just had to go to lan, vlan, set the port to access, and select my guest network. Done!

Even better is that with a 3006 router and 3006 AiMesh node(s), you can do the same for port(s) on the node(s) as well on this same page from the parent router.

 

[RandomUser777]

OK, bit the bullet and upgraded to 3006.102.4_beta1.
Everything seems to work including Aimesh with 3004 on the node.
I haven't bothered to remove/re-add the node as it all seems OK.

Found a couple issues that I don't know if they are contributed to this fork or basic ASUS firmware.

• BE96U doesn't appear to have a PHY 30 device. Currently Im seeing scans periodically which produce an error.
  
  • kernel: enet_ioctl_compat_ethctl:L1984 No PHY type PHY_TYPE_UNKNOWN at address 30 has been found.

• iPhone 13 does not like and even rejects at times, band steering.
  
  • bsd: bsd: wl0.1 Sending act Frame to REDACTED with transition target wl2.1 ssid REDACTED
    bsd: bsd: BSS Transit Response: ifname=wl0.1, event=156, token=1, status=1, mac=00:00:00:00:00:00
    bsd: bsd: BSS Transit Response: STA reject

Neither one of these are huge issues. I used a command to eliminate the iPhone 13 from even getting band steering requests at all by putting it on a deny / exempt list. Possible idea for a GUI feature for older devices putting them on a band steering exempt list when there are like 10 more more rejects for the device?

For the PHY 30 issue it comes and goes and can be suppressed with some simple SSH commands. Ultimately, the PHY 30 should be tagged to the debug log not the warnings logs.

Other than that this beta is actually going well. No major problems, no connections issues, and no crashes. I'm curiously looking into the ddosmem errors on start up and seeing what exactly they mean and if they can or need to be suppressed or moved to "debug" logging tags. Over all I'm more of a power user than a true developer but I have a good amount of experience working with OpenWRT and designing custom micro routers out of SBCs. I really am a stickler for clean logging as logging is, IMO, the best way to troubleshoot or monitor device environments.

Hey, side bar question the newish feature of MAC randomization, is there anyway in the negotiating process for the network to force that feature to OFF? Apple has OFF, Fixed, RANDOM and Android has something similar. I have had to get clever with my home internet control for my kids so that when a previously unknown MAC address is on the router it's automatically puts the device into the most restrictive access group and I have to manual pull it out after checking the device has this feature off. Chrome, while an internet browser, has the external Safe search API feature than can be enforced from the DNS filter, such as Ad Guard Home, or PiHole.

Correcting one statement in here. Seems that ALL Apple iOS devices seem to reject or not respond to the bsd.

The way I deal with MAC randomization is place my DHCP IP ranges into a black hole (you can do this with iptables rules or Network filtering rules).

 

[RMerlin]

Some wireless settings moved to the professional tab which is fine. The setting "b/g Protection" can now be disabled but after clicking "Save" it's enabled again. Thats what was missing all the time, get rid of this mechanism, but it doesn't store the disabled setting (it stays enabled even when in "n only" and/or "disable 11b" mode). Maybe this could be fixed?

Certain setting combinations will force this setting to be enabled, causing it to revert back if you try to disable it. When wireless mode is set to "Legacy" then the setting is left alone.
So, probably a regulatory/technical requirement.

 

[David Williams]

Hi All,
Since upgrading my main router and mesh nodes to 3006.102.4_beta1 I am seeing issues with some of my wireless devices. A couple of my ring cameras keep connecting and disconnecting every few minutes. Also, a couple of Feit light bulbs are doing the same. When I look at the AIMesh Topology I can actually see the devices connecting and reconnecting a couple of times a minute. The logs are showing up as follows:

Apr 13 20:11:39 wlceventd: wlceventd_proc_event(685): wl0.1: Auth 9C:76:13:A9:EB:78, status: Successful (0), rssi:0
Apr 13 20:11:39 wlceventd: _add_wlc_event_tbl(1040): client table was full
Apr 13 20:11:39 kernel: SBF: dhd0: INIT [9c:76:13:a9:eb:78] ID 65535 BFW 65535 THRSH 2048
Apr 13 20:11:39 wlceventd: wlceventd_proc_event(722): wl0.1: Assoc 9C:76:13:A9:EB:78, status: Successful (0), rssi:-72
Apr 13 20:11:39 wlceventd: _add_wlc_event_tbl(1040): client table was full
Apr 13 20:16:28 roamast: [EXAP]Deauth old sta in 1 1: DA:B8:A9:31:3A:97
Apr 13 20:16:28 roamast: wl1.1: disconnect weak signal strength station [da:b8:a9:31:3a:97]
Apr 13 20:16:28 kernel: WLC_SCB_DEAUTHENTICATE_FOR_REASON err -30
Apr 13 20:16:28 wlceventd: wlceventd_proc_event(645): wl1.1: Deauth_ind DA:B8:A9:31:3A:97, status: 0, reason: Previous authentication no longer valid (2), rssi:-93
Apr 13 20:16:28 wlceventd: _add_wlc_event_tbl(1040): client table was full
Apr 13 20:16:28 roamast: wl1.1: remove client [da:b8:a9:31:3a:97] from monitor list
Apr 13 20:16:28 wlceventd: wlceventd_proc_event(645): wl1.1: Deauth_ind DA:B8:A9:31:3A:97, status: 0, reason: Disassociated due to inactivity (4), rssi:-93
Apr 13 20:16:28 wlceventd: _add_wlc_event_tbl(1040): client table was full
Apr 13 20:39:55 wlceventd: wlceventd_proc_event(685): wl1.1: Auth DA:B8:A9:31:3A:97, status: Successful (0), rssi:-84
Apr 13 20:39:55 wlceventd: _add_wlc_event_tbl(1040): client table was full
Apr 13 20:39:55 kernel: SBF: dhd1: INIT [da:b8:a9:31:3a:97] ID 65535 BFW 65535 THRSH 2048
Apr 13 20:39:55 wlceventd: wlceventd_proc_event(722): wl1.1: Assoc DA:B8:A9:31:3A:97, status: Successful (0), rssi:-84
Apr 13 20:39:55 wlceventd: _add_wlc_event_tbl(1040): client table was full

This only started happening after upgrading to this latest beta on both the main router and the mesh nodes. The main router is a BE96U and the two nodes are AX86U_Pro's. The devices that are disconnecting are binded to the two AX86U_Pro's but other devices connecting to these two nodes are not having issues with disconnects. Another piece of information is that all the devices that are disconnecting are connected using the 2.4 Ghz channel. Should I change the log level to try and get more information? Before the upgrade the BE96U was running the previous 3006 build and the AX86U_Pro's were running the latest released Merlin builds. I have just turned off Roaming Assistant for 2.4Ghz to see if it helps any. Any other suggestions would be appreciated.

 

[RMerlin]

Do you agree that something during build is modifying client_function.js to remove the times symbol used in the client dropdown to delete offline clients? It looks like neither the line of code in client_function.js nor the tools in release/src/router/tools have changed in a long time.

Good catch. Indeed, that unicode character gets stripped during compile. Simplest fix is indeed to use a proper HTML entity instead of a hardcoded character, such as × .

No idea how long that bug has existed, it's also present on Wifi 7 devices. I do remember in the past that the "X" symbol was present, so it was broken at some point.

 

[RMerlin]

The most annoying bug is that despite IoT (SDN) network is disabled by schedule, IoT devices keep connecting to it.

Works for me. Client got disconnected once the schedule ended.

Keep in mind that each Guest Network has its own separate Wireless Scheduler:

 

[RMerlin]

@RMerlin guess it is better for u to shed a light on this?

I don't know, I don't touch any of that code.

 

[RMerlin]

I am still trying to wrap my head around the rationale for going with separate dnsmasq instances for each network in this branch. It certainly seems to complicate things - as @Aqu has found out.

Asus probably did that so if you have a separate VLAN with its own subnet and its own DHCP scope, then that dnsmasq instance will be able to handle all of this.

I am just trying to look ahead on how developers are going to handle this. Are there any NVRAM variables available to track which index numbers have been assigned to which SDNs or list the used index numbers?

There's no such list. One has to parse the SDN list to figure out which network has which index value. Check my code in DNSDirector.asp for an example on how to parse that information.

 

[RMerlin]

Apparently the Thermostat wants to use outdated TKIP

Which would typically mean WPA and not WPA2. See if by any chance they might have firmware updates for these thermostats, but I doubt it since adding WPA2 support typically also requires hardware support.

 

[RMerlin]

AX86U-Pro: In Guest Network Pro, if you configure a guest or iot network and select "use same subnet as main network" the guest/iot clients can reach everyhting inside the main network. In the previous 3004 release this was blocked. They used the same ip subnet but could only reach the internet. Is this a bug, or a new "feature"? If it's a feature, it makes gues/iot network useless if you select "same subnet",

This sounds logical to me. Same subnet = same network = everyone can talk to one another. If you don't want them to talk, then you move it to a different subnet, which will also isoldate it in its own VLAN.

This behaviour makes sense because keep in mind that Networks are no longer just wireless networks - they can also include Ethernet ports. The isolation is now handled as VLANs.

The clients I had set to use vpn (wireguard) or wan, were not retained, but easy enough to re-add them.

This is normal. Asus VPN clients are handled by VPN Fusion, which does not exist in Asuswrt-Merlin. We have different VPN client implementations.

Ethernet ports 2 and 4 are swapped around (on stock ethernet 2 shows 2.5gbps connection and eth 4 was 1gbps, with Merlin, Ethernet 2 shows 1gbps and eth 4shows 2.5gbps), not really an issue, just an observation.

Probably something that they fixed in more recent GPLs. I'm still waiting on an updated RT-BE92U GPL to address the CPU usage issue in particular.

Yes, when DNS Director is set to Router for a guest network, DNS does not resolve.

UPDATE: I have confirmed that this has been resolved in this beta (see posts #124 through #132 below).

Correct. When set to "Router" then the Guest Network's default gateway is used instead of the primary LAN IP. So, 192.168.52.1 will be used for DNS instead of 192.168.50.1, for example in the case of the first VLAN.

 

[RMerlin]

People will need to get used to the way Networks are handled in 3006 - they are completely different from 3004. Wifi 6 are currently still in an "hybrid" method where you have your main wifi, and Guest Network Pro has each guest nework with its own unique configuration. Wifi 7 devices brings it one step further, where every network (even the "main" wireless networks) are now configured separately, within the same interface, and all wireless settings are stored in a new format in nvram. I wouldn't be surprised to see Wifi 6 devices eventually also getting this new Network implementation, so people better get used to it.

A lot of settings are now configurable per network (or per guest network). These networks can have their own subnet, with their own dnsmasq instance handling a separate DHCP server, with separate DNS settings.

People with hybrid (3004 and 3006) AiMesh networks will need to be aware that 3004 nodes will not be able to share everything offered by the main router, particularly at the Guest Network level. If you have issues with AiMesh, then remove the nodes (which will automatically reset them to their factory default settings), and readd them as new nodes (by connecting to the reset node, then selecting "AiMesh Node" operation mode.

AiMesh nodes will talk to one another to advertise what feature they support, so in theory, an hybrid network is possible, but with limited functionality. If you want everything to works including VLANs, then everything will need to be on 3006.

 

[RMerlin]

I'm trying not to be too annoying (with varying degrees of success and failure), but want to help ensure as many users as possible understand how complicated third-party customization is becoming with 3006 and its newfound flexibility.

Imagine how much "fun" it was for me to a) figure out how SDN worked, b) interface DNSDirector with it, and c) interface VPN clients with it... And then a few months later they changed things around by moving each wireless network into a subunit nvram (i.e. the main network settingsa re now subunit 1, stored in wl1.1_* instead of wl1_*).

I also discovered a few bugs during my initial 3006 implementation, which I needed to have Asus look at them.

On the VPN Director Page I can select a client and/or rule hit Apply

What do you mean by "select"? There's nothing to select on that page. You can add/remove/edit rules, or enable/disable rules and clients. The Apply button is only to save rule changes, which works fine for me.

Hey, side bar question the newish feature of MAC randomization, is there anyway in the negotiating process for the network to force that feature to OFF?

No, this is entirely a client setting. The client decides on its MAC before it even starts talking to a router, so there's no way a router could have an impact on its behaviour - it's already chosen what MAC to use.

 

[RMerlin]

Good catch. Indeed, that unicode character gets stripped during compile. Simplest fix is indeed to use a proper HTML entity instead of a hardcoded character, such as × .

No idea how long that bug has existed, it's also present on Wifi 7 devices. I do remember in the past that the "X" symbol was present, so it was broken at some point.

I think I remember now that in the past, they used an image instead of a Unicode character, so that probably got broken when they switched to the character.

Anyway, I've also sent the fix upstream.