What's new

[Official Release] AiMesh Firmware v3.0.0.4.384.10007 for All Supported Products

  • 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.
@arthurlien do you mind give us more details about how a switch will block the AImesh node detection, or what kind of packet in use for the management? I didn't check it (too lazy to use wireshark), guess some multicast packet?
Yes, some switch will blocked multicast packets

我從使用 Tapatalk 的 ASUS_Z012DA 發送
 
Hey Richard, my setup is somewhat the way you desire it to be: 88u as main and 68u as node. It has been stable since the day i have flashed the fw. One of my biggest issue (other than the download speed limit) is that the roaming isnt seamless, from one router to another there is a lag time. And recently realised that my ip cam seems to be hooked onto 88u instead of 68u even though its nearer to 68u (can be verified under the list of devices connected to node).

Just think of my unsearchable case may due to RT-AC88U bought in China, while my RT-AC68U bought in Hong Kong. But still not sure about this.
 
I have set my aimesh up with wireless backhaul
instead of using same ssid, I used different ssid for both 2.4Ghz and 5Ghz.
That has given me the ability to choose channel on the aimesh router, though I do not know if it affects the node.

I also dont know if it's the best way to use aimesh as there are not much info about it.


And I also have to manually reboot my ac3100, the main aimesh router as I have not able to connect to it today.

When I access the IP for my aimesh node, I will get the following message
View attachment 11614
and after I reboot my router, I noticed the following message flood the log (i also attach the syslog)
Jan 13 16:35:46 lldpd[377]: unable to send packet on real device for wds0.3: No buffer space available
Jan 13 16:35:48 lldpd[377]: unable to send packet on real device for eth1: No buffer space available​
and it seems to have crashed the webui.
not sure if it has anything to do with the recent report on how chromecast can sent large amount of data and cause issue with router.

I have 2 RT-AC88U setup AiMesh and it works for one day, then I go for a business switch for 2 days and when I came back home, I figured out the network is having problem, the log shows exactly the same message with your problem, I reboot the main device and everything works again. Seems some kinds of buffer overflow problem, caused by memory leak?
 
Well, it seems AiMesh is still having some stability problem. However, I would like to help testing out and helping out to make it more stable. My home need at least 3-4 devices to cover all dead spots and my neighbors having tons of WiFi as well. And BTW, I have bought a set of Lyra as well, for my configuration requirements (AP mode and ethernet backhaul), it seems AiMesh is more stable than Lyra in my case. I never got Lyra working stable as well.

I am a IT person as well, I think I can offer more technical help in testing. Connect to the router using ssh and hacking the details with commands, etc.
 
Not sure what I'm supposed to do with the Device Discovery tool? It sees the AC68 after factory-reset (192.168.1.1, see screen shot) but cant do anything with it since it is on a different subnet. My network is 192.168.2.x (you can see the AiMesh Router is 2.1

Oddly enough, the tool Doesnt see the AC68 sitting at 192.168.2.3, which has joined the Mesh and has been working'mostly (I think)

I have not had any issues using the Android App to configure the reset router, but after it comes back up, with the proper IP (192.168.2.2) I can get to the login page, only the web page that say the IP changed.

Is this another bug of this version of FW?

I had the same problem, the only way that I found to fix it was changing the subnetmask for 255 255 255 255 in both routers and them finally fix the ip for second router, also, turn on the access from the LAN and WAN, you will be able to fix using the browser
 
Wife and kids are getting slightly irritated. Yesterday I came home from skiing and my wife had lost internet access on her work laptop--all SSID's. I went to fix, but found I couldn't even log into the main router from the web UI. I had to physically reboot the router, node and AP (66U). I can understand this is fairly big feature improvement and it's relatively new, but it doesn't seem like it's fully baked yet. I'm hoping they get there though. I really do.

Exactly my experience. Plus clients keep on disconnecting and reconnecting.
 
New to forum but figured i would provide feedback on my experience with aimesh

RT-AC5300 configured as router w/12/16 beta firmware 9.0.0.4.382_19612
RT-AC68R configured as a aimesh node with aimesh release 3.0.0.4.384_10007. Note this is not using wired backhaul....all wireless.

During setup i did updated each device and then performed a hard reset, using the physical reset button on each device. Added the aimesh node via web gui. performed zero configured on the node itself post hard reset.
Left default wireless Tri-band Smart Connect setting in tact. Unfortunately that includes having WPS enabled. Did change the roaming assistance from the default which i believe was -55 dBm to -70dBm. Why? Well i had been using roaming assistance prior to the release of this firmware at -70 dBm so figured at least for me it was working so why not. No technical justification for the change. :D I did turn off DHCP prior to adding the aimesh node and disabled all IPv6 features. I already have DHCP running on my network.

Overall my experience is positive. Since the release the firmware the aimesh node and it's connected devices have only completed disconnected twice. Once i physically power cycled the node, meaning i used the power button and the second time i power cycled the router via the web gui. Both times connectivity was restored. The node is at arms reach so it's not big deal and I've setup the router for a scheduled reboot so let's see if that helps.

Otherwise i can confirm some of the anomalies reported on this thread.

-aimesh node on occasion shows offline on the web gui. Note in spite of the connectivity status of the node all devices using the node still had full network/internet connectivity. This is separate from my disconnected node comments above.
-firmware showing that there's an updated but clearly it's the same version
-client list refreshes frequently. Although i had noticed this before in the 382 versions when i only had the RT-AC68R and was using it as my wireless router.

I'm also using the following features and all appear to working as before.

AIProtection with all options enabled including both parental control options.
Adaptive QOS, my personal setup is with adaptive and media streaming set.
Traffic Analyser
OpenVPN server

I did submit feedback to ASUS for the situation where the node shows as offline but with the connect devices are still able to communicated on the network.

Hope this helps.
 
Can you send a feedback by feedback function ?
I was unable to replicate it after likely dhcp stopped handing out leases (I had the app, and the settings open in the browser on my android), and I had to do factory reset, because rebooting was not helping.
 
I have restarted the main router last night a,d today, I discovered that the log has some DUMP lines, seems there are problems, I have uploaded the full log for evaluation as well:

Jan 20 16:00:34 kernel: DUMP CONSOLE: 0: wlc_send_bar: seq 0x71 tid 6
Jan 20 16:00:34 kernel: DUMP CONSOLE: 080000.329 wl1: wlc_ampdu_rx_recv_delba: AMPDU OFF: tid 0 initiator 1 reason 39
Jan 20 16:00:34 kernel: DUMP CONSOLE: 080010.423 wl1: wlc_ampdu_rx_recv_delba: AMPDU OFF: tid 0 initiator 1 reason 39
Jan 20 16:00:34 kernel: DUMP CONSOLE: 080042.379 wl1: wlc_ampdu_tx_recv_delba: AMPDU OFF: tid 6 initiator 0 reason 39
Jan 20 16:00:34 kernel: DUMP CONSOLE: 080042.692 wl1.0: wlc_send_bar: seq 0x7f tid 6
Jan 20 16:00:34 kernel: DUMP CONSOLE: 080086.491 wl1: wlc_ampdu_rx_recv_delba: AMPDU OFF: tid 0 initiator 1 reason 39
Jan 20 16:00:34 kernel: DUMP CONSOLE: 080107.625 wl1.0: wlc_send_bar: seq 0x134 tid 2
Jan 20 16:00:34 kernel: DUMP CONSOLE: 080107.762 wl1: wlc_ampdu_tx_recv_delba: AMPDU OFF: tid 6 initiator 0 reason 39
Jan 20 16:00:34 kernel: DUMP CONSOLE: 080107.804 wl1.0: wlc_send_bar: seq 0x8a tid 6
Jan 20 16:00:34 kernel: DUMP CONSOLE: 080117.100 wl1: wlc_ampdu_tx_recv_delba: AMPDU OFF: tid 2 initiator 0 reason 39
Jan 20 16:00:34 kernel: DUMP CONSOLE: 080126.441 wl1: wlc_ampdu_tx_recv_delba: AMPDU OFF: tid 6 initiator 0 reason 39
Jan 20 16:00:34 kernel: DUMP CONSOLE: 080126.542 wl1.0: wlc_send_bar: seq 0x92 tid 6
Jan 20 16:00:34 kernel: DUMP CONSOLE: 080136.134 wl1: wlc_ampdu_rx_recv_delba: AMPDU OFF: tid 0 initiator 1 reason 39
Jan 20 16:00:34 kernel: DUMP CONSOLE: 080191.825 wl1: wlc_ampdu_tx_recv_delba: AMPDU OFF: tid 6 initiator 0 reason 39
 

Attachments

  • syslog.log.txt
    80 KB · Views: 646
Initially configure them using wifi with all three (3) units in close proximity (1-3 m). Once router boots completely, initiate Search.

Does the initial setup only use WiFi to connect the Aimesh APs to the Router?... Meaning it won't use ethernet to do it?

Sent from my SM-G950U using Tapatalk
 
Does the initial setup only use WiFi to connect the Aimesh APs to the Router?... Meaning it won't use ethernet to do it?

Sent from my SM-G950U using Tapatalk

Yes, initial setup is over WiFi only.


Sent from my iPhone using Tapatalk
 
Yes, initial setup is over WiFi only.


Sent from my iPhone using Tapatalk
That is sort of true - at least that's how they instruct you to do it. I had that problem of being able to wirelessly see the node, but the setup/pairing always timed-out and failed (giving that useless message).

I got around the issue by factory resetting the node, setting it up as a wired AP, then logging-in to the AP's webui and in Administration, changed it to AiMesh Node. Followed the prompts, leaving it wired to the router. In those instructions it even mentions using a wired connection. Then went back to the router and went through the search/install stuff. Worked fine.

BTW, when I set it as an AP, I set it as a Static IP in the node and the router. Don't know if it mattered.
 
Last edited:
That is sort of true - at least that's how they instruct you to do it. I had that problem of being able to wirelessly see the node, but the setup/pairing always timed-out and failed (giving that useless message).

I got around the issue by factory resetting the node, setting it up as a wired AP, then logging-in to the AP's webui and in Administration, changed it to AiMesh Node. Followed the prompts, leaving it wired to the router. In those instructions it even mentions using a wired connection. Then went back to the router and went through the search/install stuff. Worked fine.

BTW, when I set it as an AP, I set it as a Static IP in the node and the router. Don't know if it pattered.
I switched my wired access point to AiMesh Node and it started working too. Thanks @Ronald Schwerer
 
I am getting sick of this FW always hitting the 100% of the cpu even with all the features turned off, I changed the router, I have 4 units, all with fresh install FW and with the same problem, I never had even close of 70% with olds FW, I miss the old FW from Asus
 

Attachments

  • Untitled.jpg
    Untitled.jpg
    26.7 KB · Views: 602
I switched my wired access point to AiMesh Node and it started working too. Thanks @Ronald Schwerer
I wished the app or webUI would mention that the node to search for has to be reset fully and put within 3 meters, only connected through power cord. This would have saved me (and many others I'm sure) a lot of time and trial and error. Even when it was mentioned a few times in this thread, many people have not seen or read it.
Kaizen topic for the developpers ;-)
 
- held wps and turned on
- waited 15 secs. released wps.
- waited 5 minutes

What'd I do wrong?
The only potential thing that might be wrong is that you didn't hold WPS long enough. You should power off for ~5 seconds, hold WPS and power on while holding WPS for ~25 seconds (until the power led begins to blink) then release.

Did you have to assign a new login/password other than admin/admin? I couldn't skip this step with that CFE until i changed the login & password.
 
Anyone have issues accessing their network shares when on a node but not when on the parent router?
If you mean shared drives on a Node, yes. I previously had 2 HD on my old wired AP, and after converting it to a AiMesh node, they were no longer visible. I did find a way under windows to gain a limited access but not to all my directories. Maybe the media server still worked? I don't think they get Samba mounted or if they are, there's no way to manage them. Anyway, I moved them to the Mesh router and all was normal.
 
Last edited:
The only potential thing that might be wrong is that you didn't hold WPS long enough. You should power off for ~5 seconds, hold WPS and power on while holding WPS for ~25 seconds (until the power led begins to blink) then release.

Did you have to assign a new login/password other than admin/admin? I couldn't skip this step with that CFE until i changed the login & password.

Thanks. I tried again where I held until the power started flashing on both the router and node.

I did assign a new login/password other than admin/admin.
 
I'm going to try the AiMesh again ( enjoy the aggravation) In an attempt to do a factory reset not using the GUI (AC3100), I pushed the red reset button on the back for about 15 sec while the router was turned on . The power light starts to flash slowly but never reboots I waited 5 min). Is that not the process?
 
Status
Not open for further replies.

Similar threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top