[Thread-1] [ 386.1_Alpha Build(s) ] Testing available build(s)

[TCoreX]

have now switched to Alpha 4 and the problem continues to arise with the surface that it hangs, OpenVPN no longer works over time and the Internet is cut off over time. Restarting solves the problem in the short term, as I already noticed with Alpha 3. any ideas on that?

 

[bluecatus]

How to mesh all guest wifi on both aimesh router and aimesh node? Now merlin have just got mesh on only the first guest wifi (both 2.4 and 5GHz).

 

[Darkje]

@RMerlin can we safely cross flash gt-ac2900 and the ac-86u?

 

[bbunge]

How to mesh all guest wifi on both aimesh router and aimesh node? Now merlin have just got mesh on only the first guest wifi (both 2.4 and 5GHz).

AiMesh 2.0 only will sync the first Guest of 2.4 and 5 GHZ to the nodes. Merlin does not control this.

 

[JoJoDaClown]

AC-5300 Alpha 4: Flash, WPS Reset, then GUI Reset, Reboot, Quick Setup: WiFi crashes after 1 hour (all bands channel 0 and not broadcasting). Nothing in Log except "rc_service: watchdog 7145:notify_rc start_cfgsync"

 

[RMerlin]

The LED radio button for under AiMesh tab, Management sub-tab (above Enable Radio buttons) is missing for the the rebuilt RT-AX58U Alpha 4 firmware.

Everything related to AiMesh is entirely in Asus`s backyard.

 

[RMerlin]

@RMerlin can we safely cross flash gt-ac2900 and the ac-86u?

No, they are two different devices. You cannot crossflash Asuswrt.

 

[Unisoft]

Noticed a problem since alpha4. As soon as I change some wireless setting and apply it, my wan connection goes down. Only solution is to reboot the router.

Fine on my two RT-AX86U routers. I can make changes and my WAN didn't go down.

 

[Unisoft]

Is everyone else seeing all devices only listed under Wired Interface in the Client List? ie., nothing is listed in a wireless group.

Fine on my two RT-AX86U routers I have. Wireless lists ok in network map.

 

[visortgw]

Everything related to AiMesh is entirely in Asus`s backyard.

I figured that was the case, but since it was specific to only the RT-AX58U (RT-AC86U Alpha 4 shows it), I wanted to throw it out there. Both RC 2-8 and RC 2-9 from Asus have the LED control present for RT-AX58U nodes. I have currently settled on Alpha 4 for RT-AX88U primary and RC 2-9 for RT-AX58U/RT-AC86U AiMesh nodes.

 

[octopus]

I'm using vpn client1 and there is som rules missing:

Table 111
0.0.0.0/1 via 10.128.0.1 dev tun11
128.0.0.0/1 via 10.128.0.1 dev tun11

IP Routes

158.xxx.xxx.1 dev eth0 proto kernel scope link
217.64..xxx.xxx via 158.xxx.xxx.1 dev eth0

Accept DNS Configuration: EXCLUSIVE
Force Internet traffic through tunnel: Policy Rules

 

[brianward317]

I figured that was the case, but since it was specific to only the RT-AX58U (RT-AC86U Alpha 4 shows it), I wanted to throw it out there. Both RC 2-8 and RC 2-9 from Asus have the LED control present for RT-AX58U nodes. I have currently settled on Alpha 4 for RT-AX88U primary and RC 2-9 for RT-AX58U/RT-AC86U AiMesh nodes.

I did the same thing. I am using Alpha 4 for RT-AX88U and AC68U. Just upgraded my AC3100 to RC 2-9 and it fixed the aimesh issue I was having. I'll move back to Merlins 386 for 3100 model once it reaches beta or goes live.

 

[RMerlin]

I'm using vpn client1 and there is som rules missing:

Those routes are for redirecting all traffic through the tunnel, which is obviously not what you'd want with policy-based routing, therefore these two routes are explicitely dropped.

 

[octopus]

Those routes are for redirecting all traffic through the tunnel, which is obviously not what you'd want with policy-based routing, therefore these two routes are explicitely dropped.

Okey, I got it but I have these in 384.19 build with same config.

 

[JoJoDaClown]

Regarding adding AiMesh Nodes under RT-AC5300 and not being able to on 386.1Alpha: If I revert back to 384.19, I can add my node without issue.
Additionally, all clients are being displayed properly in their connection type in the client list.
Furthermore, I see no "rc_service: watchdog 7145:notify_rc start_cfgsync" in the Log

 

[ecantona9]

I did the same thing. I am using Alpha 4 for RT-AX88U and AC68U. Just upgraded my AC3100 to RC 2-9 and it fixed the aimesh issue I was having. I'll move back to Merlins 386 for 3100 model once it reaches beta or goes live.

Any improvement going from Alpha 3 to Alpha 4?

 

[brianward317]

Any improvement going from Alpha 3 to Alpha 4?

I have AX88 and RT-68 on Alpha 4 and have zero issues currently. I have my RT-3100 on RC 2-9 and it seems to be stable too. I won't move the RT-3100 model over until beta or I know that Aimesh is stable on it. RC 2-9 fixed stability issues with my RT-3100, so guessing matter of time before Merlin fixes and resolves the issues.

 

[ecantona9]

I have AX88 and RT-68 on Alpha 4 and have zero issues currently. I have my RT-3100 on RC 2-9 and it seems to be stable too. I won't move the RT-3100 model over until beta or I know that Aimesh is stable on it. RC 2-9 fixed stability issues with my RT-3100, so guessing matter of time before Merlin fixes and resolves the issues.

Ok. Thanks. I thinking about upgrading but I'm stable on the early Alpha 3 versions for the 86u and the ac3100

 

[bbunge]

27 hours up on alpha4 with no glaring errors. Running Diversion and FlexQOS. Have noticed RAM usage going up and using swap but I attribute that to Diversion (my first use of Diversion - getting use to the way it works).

Of note is the IOT devices in the guest 1 networks (2.4 and 5 GHZ) are using their hard coded DNS servers. I do have DNS Filtering Router enabled and I am assuming that only covers the LAN (192.168.50.0/24) subnet. The guest 1 networks (192.168.101.0/24 and 192.168.102.0/24) do try to assign the router (192.168.101.1 and 192.168.102.1) as DNS servers but the hard coded DNS is ignoring the DHCP. I really do not have a problem with this as I feel the guest network is working as intended. But, might there be a future feature that DNS filters the guest networks?

 

[octopus]

Those routes are for redirecting all traffic through the tunnel, which is obviously not what you'd want with policy-based routing, therefore these two routes are explicitely dropped.

Something is strange here, trying to use client 1 and 3 then client 3 don't get public ip (unknown).

RPDB Rules
0: from all lookup local
10001: from all to 213.136.63.73 lookup main
10101: from 192.168.12.153 lookup ovpnc1
10102: from 192.168.12.111 lookup ovpnc1
10103: from 192.168.12.157 lookup ovpnc1
10104: from 192.168.12.216 lookup ovpnc1
32766: from all lookup main
32767: from all lookup default

Table ovpnc1
default via 10.128.0.1 dev tun11
10.128.0.0/22 dev tun11 proto kernel scope link src 10.128.3.78
10.129.0.0/22 dev tun13 proto kernel scope link src 10.129.3.153 <<<== ???
Table ovpnc2
Table ovpnc3
0.0.0.0/1 via 10.129.0.1 dev tun13
default via 10.129.0.1 dev tun13
10.129.0.0/22 dev tun13 proto kernel scope link src 10.129.3.153
128.0.0.0/1 via 10.129.0.1 dev tun13
Table ovpnc4
Table ovpnc5

Table main
default via 158.174.112.1 dev eth0