What's new

Beta ASUSWRT 386 RC2 public beta with full functions AiMesh 2.0

  • 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.
@Asus team

I guess I found the reason why IOT devices are not connecting to AImesh, respectively d/c one by one over time.
=> The problem is that the DCHP server only gives a proper netmask after reboot after that IOT devices do not get any valid NETMASK with the IPadress

You can reproduce the problem with a WEMOS D1 MINI
1) connect to your wemos over serial while it connects to AIMESH
2) first have AImesh DHCP server running. In my case netmask is 255.255.0.0
=> you will see in serial that the D1 is rebooting over and over and shows a strange netmask 255.255.0.(unreadable character)
3) now you stop dhcp from AImesh and activate dhcp from another old router
=> D1 mini connects within seconds and gets the right netmask 255.255.0.0

This also explains why IOT with static IP connect to AImesh. This behavior can be reproduced.

Can you please fix this? Router that does not connect IOT devices is not really usefull novadays.... I also reported it to Ivory Cheng from your support... hope the message gets to the developper.

Lobo
 
@ASUSWRT_2020 – Ran into my first issue. I've got RC-6 running on an AiMesh network that now includes a GT-AC5300 (main)/RT-AC68U (node)/Blue Cave (node). I upgraded to 386 RC-6 on both supported devices and performed a factory reset for all three. Roughly five hours after setting up, I'm unable to access the GUI via any web browser or the settings via the app. Both wired and wireless devices are affected. Looks like I'm going to have to reboot to regain access.

Despite the inability to access the GUI/settings, all LAN/WAN traffic seems fine.

Anyone else come across this?
 
@ASUSWRT_2020 – Ran into my first issue. I've got RC-6 running on an AiMesh network that now includes a GT-AC5300 (main)/RT-AC68U (node)/Blue Cave (node). I upgraded to 386 RC-6 on both supported devices and performed a factory reset for all three. Roughly five hours after setting up, I'm unable to access the GUI via any web browser or the settings via the app. Both wired and wireless devices are affected. Looks like I'm going to have to reboot to regain access.

Despite the inability to access the GUI/settings, all LAN/WAN traffic seems fine.

Anyone else come across this?
How did you access your router with browser, https (?) ... have you tried 192.168.1.1 (I am not sure what is the default IP address of GT-AC5300). Hope you find your solution :)
 
This is to report an RT-AC86U RC2-6 webUI anomaly...

I switched Smart Connect ON with same SSIDs and Applied. Then I reverted to Smart Connect OFF and previous different SSIDs so that I could login to a wireless IP phone to add a network connection the easy way for the same SSID. Before I applied the reverted settings for Smart Connect OFF, the webUI displayed the following oddness. After I applied the Smart Connect OFF settings, these odd displays disappeared... so all appears normal now.

Screenshot 2020-10-16 081453.JPEG


Screenshot 2020-10-16 081546.JPEG


Also notice the slight table side edge misalignment in the second/lower image.

OE
 
How did you access your router with browser, https (?) ... have you tried 192.168.1.1 (I am not sure what is the default IP address of GT-AC5300). Hope you find your solution
Yes, HTTPS as well as both the router.asus.com and 192.168.1.1 addresses. No luck. After the reboot, the Blue Cave (wireless backhaul) also had to be rebooted for it to rejoin the network. But the system has since been running overnight and is still accessible via GUI/app, knock on wood, so maybe it was a post-setup glitch that's now resolved. I've got 60+ LAN devices, so there's always a possibility that one of them started causing issues when I swapped out my routers.
 
@Asus team

I guess I found the reason why IOT devices are not connecting to AImesh, respectively d/c one by one over time.
=> The problem is that the DCHP server only gives a proper netmask after reboot after that IOT devices do not get any valid NETMASK with the IPadress

You can reproduce the problem with a WEMOS D1 MINI
1) connect to your wemos over serial while it connects to AIMESH
2) first have AImesh DHCP server running. In my case netmask is 255.255.0.0
=> you will see in serial that the D1 is rebooting over and over and shows a strange netmask 255.255.0.(unreadable character)
3) now you stop dhcp from AImesh and activate dhcp from another old router
=> D1 mini connects within seconds and gets the right netmask 255.255.0.0

This also explains why IOT with static IP connect to AImesh. This behavior can be reproduced.

Can you please fix this? Router that does not connect IOT devices is not really usefull novadays.... I also reported it to Ivory Cheng from your support... hope the message gets to the developper.

Lobo


That would be an interesting discovery.
I tried reproducing it, but I'm not able. But my uptime is 14h, so I'll try again in a couple of days.
Maybe when it happens again to you, can you try to reproduce it on a laptop? Ideally while running Wireshark so you can capture a DHCP offer with the strange character. I'm sure such a capture will convince Asus they have a problem. If you need any help on how to Wireshark and force ip address renew on a laptop, just DM me (it looks like you are skilled, but worth offering the help)
And do send feedback directly from the router.

I have a device that uses the same ESP 8266 adapter as your Wemos. And my device also suffers every now and then. And it all started the day I started using this beta release.
But I can't attach a console to my device, it's a black box.
 
This is to report an RT-AC86U RC2-6 webUI anomaly...

I switched Smart Connect ON with same SSIDs and Applied. Then I reverted to Smart Connect OFF and previous different SSIDs so that I could login to a wireless IP phone to add a network connection the easy way for the same SSID. Before I applied the reverted settings for Smart Connect OFF, the webUI displayed the following oddness. After I applied the Smart Connect OFF settings, these odd displays disappeared... so all appears normal now.

View attachment 26906

View attachment 26907

Also notice the slight table side edge misalignment in the second/lower image.

OE

Another issue noticed since switching to Smart Connect and same SSIDs...

Both guest WLANs were changed from OE-24 Guest and OE-50 Guest to the same OE Guest. Many hours later I noticed that the remote node was still broadcasting OE-50 Guest. I then performed a system reboot and that appears to have corrected the remote node 5.0 broadcast to OE Guest.

It would appear that the 5.0 guest WLAN SSID setting did not sync to the remote node after selecting Apply.

OE
 
@ASUSWRT_2020

The client lists which are displayed in the new AiMesh, for nodes and main router/s, can they please be sorted, using an IP address for each of the client names? Right now, it looks like there is no sorting at all occurring of attached clients, at least nothing obvious, I can see. The old client list display sort can be changed by clicking on column titles. The new client listing for AiMesh has no ability to change the display sorting of connected clients. I am suggesting to use an IP address sort for the displaying of connected clients at a minimum on original display. Which then equals/corresponds to/for current old/initial client display listing.
@ASUSWRT_2020

Any chance of getting that problem fixed?

New Aimesh 2 client listing, sort problem....Has NO function/ability to sort by clients.
 
@ASUSWRT_2020

Another small GUI display problem. On the node details window, which displays when clicking on the node and then selecting "More Config, can you please fix the display wording to MAC Address and Connection Type.

1602895308730.png
 
Last edited:
That would be an interesting discovery.
I tried reproducing it, but I'm not able. But my uptime is 14h, so I'll try again in a couple of days.
Maybe when it happens again to you, can you try to reproduce it on a laptop? Ideally while running Wireshark so you can capture a DHCP offer with the strange character. I'm sure such a capture will convince Asus they have a problem. If you need any help on how to Wireshark and force ip address renew on a laptop, just DM me (it looks like you are skilled, but worth offering the help)
And do send feedback directly from the router.

I have a device that uses the same ESP 8266 adapter as your Wemos. And my device also suffers every now and then. And it all started the day I started using this beta release.
But I can't attach a console to my device, it's a black box.

I tried to reproduce it with no luck. The only issue I can find is sometimes, like 2 out of 10 attempts, Asus needs 3.5-4 seconds to provide an Offer after Discover message is send by the client. It shouldn't be, as router has CPU below 10%, but it's not unacceptable as far as I know. My Linux laptop does not send another discover, so it's happy with that timeout.
Still trying...
 
"protocol 0800 is buggy, dev eth8" is back spamming syslog server.
It used to be an issue back early 2018 and there was a lot of chatter here. Back then it was shown in System Logs in GUI, now it's only send to syslog server.
Asus fixed it soon after, but it seems that is back in this release (or even in other beta releases, I don't have old enough logs).
Yes, I'm using link bonding to a Synology. For several years, the same unit, the same configuration.
I'm sending a feedback form to Asus.
 
I tried to reproduce it with no luck. The only issue I can find is sometimes, like 2 out of 10 attempts, Asus needs 3.5-4 seconds to provide an Offer after Discover message is send by the client. It shouldn't be, as router has CPU below 10%, but it's not unacceptable as far as I know. My Linux laptop does not send another discover, so it's happy with that timeout.
Still trying...
I have seen this on my rt-ax88u on some iot devices, it can't connect to router. Now I have put static ips on them then there is no problem. They are always connected. I have also seen this with aimesh 1.0. They dont manage to keep connected on some of the aimesh nodes. I think it's the same thing, unfortunately can't put static ip on those wifi plugs. Very annoying. I wonder if a external dhcp server would be better, seems unnecessary work when it should work.
 
I have seen this on my rt-ax88u on some iot devices, it can't connect to router. Now I have put static ips on them then there is no problem. They are always connected. I have also seen this with aimesh 1.0. They dont manage to keep connected on some of the aimesh nodes. I think it's the same thing, unfortunately can't put static ip on those wifi plugs. Very annoying. I wonder if a external dhcp server would be better, seems unnecessary work when it should work.

That's my next step to try: I can easily move DHCP server off Asus to Synology. Annoying, but worth trying that path.
 
New One:

Just had two 'ghost' nodes on my AiMesh network.

The main GT-AX11000 router and two RT-AX92U nodes and two further two nodes beneath them, both disconnected, both with the name of Home. The RTs have custom names so didn't appear to be duplicates.

Gone after a reboot but connections were starting to getting a bit wobbly beforehand.
 
Update from me. I originally was trying to use a AC68U as an AiMesh node using wireless backhaul to a AX88U, however whenever I enabled guest networks with intranet isolation pushed out to the mesh node I started getting packetloss on the main WLAN network (the guest was fine). If I set the guest network to be on the router only there was no problem. I sent feedback and was contacted by @ASUSWRT_2020 who said they tried my configuration but were unable to recreate the problem.

Anyway, I managed to pick up an AX92U on prime day for 25% off. Updated it with RC2-6 and added it as the AiMesh node and I'm now not having any problems with packet loss, even with the guest network enabled on the mesh node. The extra 5Ghz radio is great for the backhaul as I also used wired clients on the node which benefit from the extra connection speed back to the main router. So, for my setup RC2-6 seems really good and stable so far (30 hours of uptime).
 
There is a current thread about guest WLAN isolation on stock firmware:

Has anyone examined RC2-6 guest WLAN isolation and have results to share?

The above thread raises the question, 'can you scan/see clients on the LAN/WLANs but still not access them from the guest WLANs?'. I'm not sure what 'scan' means in the above thread.

OE
 
There is a current thread about guest WLAN isolation on stock firmware:

Has anyone examined RC2-6 guest WLAN isolation and have results to share?

The above thread raises the question, 'can you scan/see clients on the LAN/WLANs but still not access them from the guest WLANs?'. I'm not sure what 'scan' means in the above thread.

OE
Using 'Device Discovery' with the WiFiman Ubiquiti app on RC2-6 guest network with intranet isolation enabled the only devices I can find are the main router (albeit with a 192.168.102.1 address) and some amazon firesticks that are also on the guest network. None of the devices on the main network appear. To do a proper scan would require a tool like nmap, but I don't have that installed on any of my guest devices at the moment to test.
 
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