ASUS RT-AC5300 Firmware version 3.0.0.4.384.45149
- Thread starter LimJK
- Start date
OzarkEdge
Part of the Furniture
I'm not judging. I only want to understand tri-band usage... when does it make a difference, if any, and is it worth any additional cost.
I also would not assume ASUS is persecuting anyone, much less unnecessarily. I suspect they are managing their development overhead at the expense of losing the 'extra' 5G band, perhaps for only a short term.
OE
Swistheater
Very Senior Member
From what I notice, in my clients list, I switch it to interface tab..... So each of my devices are listed as connected to 5G-1 even though the backhaul for the 5G channel is 5G-2. it doesn't matter which node the wireless device is connected to.... so maybe there is a little bit of load balancing happening between the backhaul and the front-haul.... this is why I am not quite sure I am ready to dismiss this firmware yet..... Note I decided to leave my 5G-2 hidden and not rename it....- though I did un hide it for a while just to test it.. I do not think it hurt simply because I am hard wired on all nodes except 1, but I decided to go back to original hidden feature just to see if I notice any different behaviors.
whitehawk82
New Around Here
A lot of people seem to be overlooking or are completely unaware of the primary flaw of AIMesh. While the loss of the second radio is infuriating and what brought me here as I run a 5300 for my primary and a RT68U as my secondary theirs no high-band radio for the secondary to use for a backhaul, so yes. Immediate loss of the 2nd 5Ghz on the 5300. WTF!?
However, the primary flaw is that in a good meshed roam-able network (like those you'd find in enterprises) NONE of the APs within range of each other use the same channel, there are several reasons for this.
* 2 APs on the same channel cause interference reducing performance, so partly they want to give as much bandwidth for as much clients as possible and the central controller assigns different channels either by manual config from the network engineer, or by automated config measuring signal levels.
* your devices have roaming algorithms that determine when to roam, sometimes assisted by the network sending specific control frames to trigger it and say "I think you'd be better served elsewhere" which causes the device to re-search for and join another AP (assisted roaming) and this happens really fast when a central controller is involved which is what AIMesh is attempting to do. However, in normal cases the signal gets to a specific threshold and your device looks for a closer AP on it's own. "Smart Connect" is essentially "Band Steering" and assists in pushing clients where the control system wants them to go using the assisted roaming.
In large systems that also have self-healing meshs they will use the second radio like ASUS is trying to do, but only if supported by all of the close by APs. And of course this is configurable, if you have a really reliable ethernet backhaul that also supplies POE to the AP, typically the signal itself is not going to drop if the AP has power, more than likely the whole AP gets cut/unplugged/no power. Therefore I usually to squeeze as much bandwidth as possible enable both 5Ghz radios and let them sort out which channel they want and you end up with non-channel overlapped aps, its not uncommon to be in a spot and see the Same SSID on 3 or 4 different 2.4Ghz channels and 6 to 8 5Ghz depending on the density. Then the channels get overlapped and re-used further away where the AP's cant see each other.
When enabled these mesh's will use a common channel to talk to each other for the backhaul. sometimes multiple APs will use the same channel. sometimes they will channel hop to talk to each neighbor independently. But 9 times out of 10, the wired backhaul is up on these APs and the mesh links are completely unused although some can be used for heavy traffic overflow when the ethernet is saturated in a busy area. And some of these APs have bonded ethernet or multi-gig ethernet (2.5Gb links are fairly new, not sure why they didnt go to 10Gb)
Anyway, whats my point? In any of those networks the client access radios are all on separate channels away from each other for smoother operation. What ASUS has done with AIMesh is created a half single-AP, half controller-based implementation that uses the multiple APs all on the same channel. Your device sends out a packet, it may be received by multiple APs in the mesh, so multiple copies can saturate your switches. Then the controller goes, "Oh, that devices is strongest on AP 2, I'm going to send responses there" but then the other AP's hear the response and have to discard the packet to not cause loops. Essentially a multi-receive single transmit type of system. Also if its local ant not going out one of your routers as a gateway, or you're using this as AP only and have a firewall. Your switch may be flapping back and forth with your devices MAC on your AP ports when it receives multiple copies, so the return traffic can be completely inconsistent as from what I can tell sniffing the network the traffic is not tunneled to the primary router (which is another method of enterprise wifi)
Roaming doesn't work very well in this setup at least in my experience as in a normal system you associate with an AP and only talk to that AP. The wired switch then learns your MAC address's port and by that what AP is talking to you and routes the packets appropriately. I have a switch in my garage and a 20Gbps backbone to my office where my primary router is... There have been numerous times that I turn on my phone, associate to the 5300 in my office, walk to the other end of the house where I should immediately hand off to my garage router, but because my phone still has enough signal to hold on to the 5300 it doesn't roam. But alas I'm too far away for good SNR and before it decides to roam, the traffic is being picked up by the garage, sent across the network, and the replies are still being broadcast from the 5300. How do I fix this? Remove the enterprise grade switch from the equation and run a dedicated wire between the 5300 and the 68U so that the switch doesnt get confused about where my device is. But if they would just let the 5300 and the 68U operate on independent channels, it'd likely fix this! And as others have said, where we don't have a tri-band secondary AP, but connected with Ethernet, just give us back our other band for client use! it's in the center of my house where most of my devices are!
By the way some poorly written device roaming algorithms don't use the signal level of the specific MAC you're connected to, but only the signal level of anything broadcasting that SSID on the same channel. I've had to correct manually configured enterprise networks to fix their channel layouts because of this.
I haven't played with any of the other new consumer mesh's out there, do they all use the same channel for access?
Man, I wish I could afford a real controller-based solution. Or even just UniFi, I just hate running Java for anything. This AIMesh has never worked properly and may just not be worth having as most of the time my secondary router just doesn't work and I have to reset my devices connection.
However, the primary flaw is that in a good meshed roam-able network (like those you'd find in enterprises) NONE of the APs within range of each other use the same channel, there are several reasons for this.
* 2 APs on the same channel cause interference reducing performance, so partly they want to give as much bandwidth for as much clients as possible and the central controller assigns different channels either by manual config from the network engineer, or by automated config measuring signal levels.
* your devices have roaming algorithms that determine when to roam, sometimes assisted by the network sending specific control frames to trigger it and say "I think you'd be better served elsewhere" which causes the device to re-search for and join another AP (assisted roaming) and this happens really fast when a central controller is involved which is what AIMesh is attempting to do. However, in normal cases the signal gets to a specific threshold and your device looks for a closer AP on it's own. "Smart Connect" is essentially "Band Steering" and assists in pushing clients where the control system wants them to go using the assisted roaming.
In large systems that also have self-healing meshs they will use the second radio like ASUS is trying to do, but only if supported by all of the close by APs. And of course this is configurable, if you have a really reliable ethernet backhaul that also supplies POE to the AP, typically the signal itself is not going to drop if the AP has power, more than likely the whole AP gets cut/unplugged/no power. Therefore I usually to squeeze as much bandwidth as possible enable both 5Ghz radios and let them sort out which channel they want and you end up with non-channel overlapped aps, its not uncommon to be in a spot and see the Same SSID on 3 or 4 different 2.4Ghz channels and 6 to 8 5Ghz depending on the density. Then the channels get overlapped and re-used further away where the AP's cant see each other.
When enabled these mesh's will use a common channel to talk to each other for the backhaul. sometimes multiple APs will use the same channel. sometimes they will channel hop to talk to each neighbor independently. But 9 times out of 10, the wired backhaul is up on these APs and the mesh links are completely unused although some can be used for heavy traffic overflow when the ethernet is saturated in a busy area. And some of these APs have bonded ethernet or multi-gig ethernet (2.5Gb links are fairly new, not sure why they didnt go to 10Gb)
Anyway, whats my point? In any of those networks the client access radios are all on separate channels away from each other for smoother operation. What ASUS has done with AIMesh is created a half single-AP, half controller-based implementation that uses the multiple APs all on the same channel. Your device sends out a packet, it may be received by multiple APs in the mesh, so multiple copies can saturate your switches. Then the controller goes, "Oh, that devices is strongest on AP 2, I'm going to send responses there" but then the other AP's hear the response and have to discard the packet to not cause loops. Essentially a multi-receive single transmit type of system. Also if its local ant not going out one of your routers as a gateway, or you're using this as AP only and have a firewall. Your switch may be flapping back and forth with your devices MAC on your AP ports when it receives multiple copies, so the return traffic can be completely inconsistent as from what I can tell sniffing the network the traffic is not tunneled to the primary router (which is another method of enterprise wifi)
Roaming doesn't work very well in this setup at least in my experience as in a normal system you associate with an AP and only talk to that AP. The wired switch then learns your MAC address's port and by that what AP is talking to you and routes the packets appropriately. I have a switch in my garage and a 20Gbps backbone to my office where my primary router is... There have been numerous times that I turn on my phone, associate to the 5300 in my office, walk to the other end of the house where I should immediately hand off to my garage router, but because my phone still has enough signal to hold on to the 5300 it doesn't roam. But alas I'm too far away for good SNR and before it decides to roam, the traffic is being picked up by the garage, sent across the network, and the replies are still being broadcast from the 5300. How do I fix this? Remove the enterprise grade switch from the equation and run a dedicated wire between the 5300 and the 68U so that the switch doesnt get confused about where my device is. But if they would just let the 5300 and the 68U operate on independent channels, it'd likely fix this! And as others have said, where we don't have a tri-band secondary AP, but connected with Ethernet, just give us back our other band for client use! it's in the center of my house where most of my devices are!
By the way some poorly written device roaming algorithms don't use the signal level of the specific MAC you're connected to, but only the signal level of anything broadcasting that SSID on the same channel. I've had to correct manually configured enterprise networks to fix their channel layouts because of this.
I haven't played with any of the other new consumer mesh's out there, do they all use the same channel for access?
Man, I wish I could afford a real controller-based solution. Or even just UniFi, I just hate running Java for anything. This AIMesh has never worked properly and may just not be worth having as most of the time my secondary router just doesn't work and I have to reset my devices connection.
Last edited:
Actually it doesn’t have packets going to all AP’s and the strongest AP responding, the clients connect to a single BSSID at a time still.
I have spent a lot of time watching my clients hop between AP’s as I walk around.
The fact they are all on the same channel I agree seems a little odd, but I assume the AP’s are smart enough to reduce some of the issues with crowding one channel.
It also means in an urban environment you are not hogging many channels. Enterprises with meshes are generally in their own building, this is residential with neighbours very close.
Sent from my iPhone using Tapatalk
I have spent a lot of time watching my clients hop between AP’s as I walk around.
The fact they are all on the same channel I agree seems a little odd, but I assume the AP’s are smart enough to reduce some of the issues with crowding one channel.
It also means in an urban environment you are not hogging many channels. Enterprises with meshes are generally in their own building, this is residential with neighbours very close.
Sent from my iPhone using Tapatalk
Your specific roaming to garage and network slow to catch up sounds like a Gratuitous ARP issue.
Ensure STP is disabled on your switch as that often break GARP (especially on Cisco).
With GARP working you should not get the issue you describe at all. If you are perceiving a delay then a timeout and normal ARP request is having to be sent.
Sent from my iPhone using Tapatalk
Ensure STP is disabled on your switch as that often break GARP (especially on Cisco).
With GARP working you should not get the issue you describe at all. If you are perceiving a delay then a timeout and normal ARP request is having to be sent.
Sent from my iPhone using Tapatalk
whitehawk82
New Around Here
Well in this case normal traffic should allow the switch to re-learn. But I have maybe not clearly stated run a separate cable between the two ASUS routers. so at this time that's definitely not the issue. I've spent more time than I'd like to troubleshooting this as when I get home I really don't feel like touching networks anymore. I think the main point I was trying to make is there are things ASUS could do to fix these problems, fairly easily as they've been solved for many years already.
whitehawk82
New Around Here
I've seen the same traffic across multiple ports, while I agree your device should target, wireless is wireless and it does hit all the APs by nature... wether the AP listens and forwards it is another thing. AIMesh seems to due to the traffic being on both ports when I had them connected to the cisco switch. Saw it.
The channel options should be configurable. There are many environments where shared office buildings are more dense than urban residential. and yes 2.4 is instantly a no-go in many cases. But 5Ghz given it's low penetration abilities not so much. I personally live on several acres so... Not a problem for me. It goes both ways. Same channel best by default? probably... but let me override in the "professional" settings.
The channel options should be configurable. There are many environments where shared office buildings are more dense than urban residential. and yes 2.4 is instantly a no-go in many cases. But 5Ghz given it's low penetration abilities not so much. I personally live on several acres so... Not a problem for me. It goes both ways. Same channel best by default? probably... but let me override in the "professional" settings.
Last edited:
I agree it should be configurable, but this is a home solution.
I honestly think something is setup wrong with your setup.
I use Powerline for backhaul, so essential a big virtual switch, and I can roam with a VoIP call in progress with not blip in speech in either direction. You should definitely be able to do the same if you get the switch configured right.
Sent from my iPhone using Tapatalk
I honestly think something is setup wrong with your setup.
I use Powerline for backhaul, so essential a big virtual switch, and I can roam with a VoIP call in progress with not blip in speech in either direction. You should definitely be able to do the same if you get the switch configured right.
Sent from my iPhone using Tapatalk
whitehawk82
New Around Here
*shrug* I manage about 10 different vendor solutions daily Cisco (tunneled of course so its completely different), Meraki, Aruba, older HP (Non-Aruba) Aerohive, Ubiquiti *shudder*. Cisco switches, HP switches, Juniper switches etc.. None of them have the issue. Been a network engineer for 30 years. Wasn't trying to hijack this into a troubleshooting thread. Just adding my complaint about easy things they could take from the enterprise world to make this better.
And the issue persists without the switch in the equation. Direct 68U Wan->5300 port 4
And the issue persists without the switch in the equation. Direct 68U Wan->5300 port 4
whitehawk82
New Around Here
Also, not sure what device you have that roams seamlessly... but one of my devices is better than my other. That one is my primary and the one I get most frustrated over, I'm pretty sure it's one of those I referred to that doesnt take into account the specific AP but only the overall signal of the SSID on a channel. Thats why separate channels would likely solve my issue as it does not have this issue if I break my mesh and just use different SSIDs on different channels with the current node in just a dumb AP mode. thinking about going back to that as it will give me back the other 5Ghz band as well due to the original topic in this post about the new firmware.
whitehawk82
New Around Here
There ya go, yet older iOS's had issues with roaming shoot I had one that didn't even work with ASUS APs for a while until an update. constant drop offs. Mine is android (notorious for holding on to a connection for as long as it can), my laptop works better, but I was able to set the roaming algorithm on the WiFi chip using vendor drivers and set it to be more aggressive. But anyway love the discussion but I'd definitely like to see them offer the option for multi-channel as I think it'd help a lot of people. Not that they watch places like this. But I've already sent my feedback, maybe if several others do?
Last edited:
The only possible case this might be OK for is those setups that use only tri-band router and nodes.
What about setups that don't have all tri-band devices!
All this does is make the already poor backhaul node selection even worse.
Clueless just isn't a strong enough description for this, downright stupid is closer to the mark.
Arthur,Arthur,
May I know if there is any update after you internal discussion on 5G2_DWB matter where our Triband is reduced to DualbandThanks
Bump ... hoping to get some attention ... after over 2.5 months
May I know if there is any update after you internal discussion on 5G2_DWB matter where our Triband has been reduced to Dualband
Thanks
Jim Kirk
Occasional Visitor
Arthur,
Bump ... hoping to get some attention ... after over 2.5 months
May I know if there is any update after you internal discussion on 5G2_DWB matter where our Triband has been reduced to Dualband
Well LimJK you continue to have my attention
.I second LimJK on his request. I am also waiting for the next FW release for my 3 RT-AC5300's so I may solve the problem I reported with FW 45149 here.
https://www.snbforums.com/threads/3...384-45149-quickly-downgraded-384-32799.50296/
Jim Kirk
Occasional Visitor
Well LimJK you continue to have my attention
I second LimJK on his request. I am also waiting for the next FW release for my 3 RT-AC5300's so I may solve the problem I reported with FW 45149 here.
https://www.snbforums.com/threads/3...384-45149-quickly-downgraded-384-32799.50296/
Have there been any developments on this issue? Seems like further work on the next FW >45149 has stopped.
HuskyHerder
Senior Member
I have seen no mentions nor even rumors and speculation.....
Similar threads
Similar threads
Similar threads
-
Release ASUS GT-AC5300 Firmware version 3.0.0.4.386_51569 (2024/11/12)
- Started by fruitcornbread
- Replies: 0
-
Release ASUS RT-AC5300 Firmware version 3.0.0.4.386_48430 (2024/11/12)
- Started by fruitcornbread
- Replies: 0
-
Release ASUS GT-AC5300 Firmware version 3.0.0.4.386_51529 (2023-11-27)- Started by Diveblaster
- Replies: 3
-
Release ASUS ZenWiFi XP4 Firmware version 3.0.0.4.386_47475 (2024/11/25)
- Started by fruitcornbread
- Replies: 0
-
Release ASUS RT-BE88U Firmware version 3.0.0.6.102_37094 (25 Nov. 2024)- Started by Treadler
- Replies: 2
-
Release ASUS RT-BE86U Firmware version 3.0.0.6.102_37174 (2024/11/22)
- Started by KevTech
- Replies: 0
-
Release ASUS TUF-AX5400 Firmware version 3.0.0.4.388_24194 (2024/11/22)
- Started by fruitcornbread
- Replies: 1
-
Release ASUS ZenWiFi ET9 Firmware version 3.0.0.4.388_25146 (2024/11/19)
- Started by fruitcornbread
- Replies: 1
-
Release ASUS TUF-AX3000 V2 Firmware version 3.0.0.4.388_23848 (2024/11/19)
- Started by fruitcornbread
- Replies: 2
-
Release ASUS ZenWiFi XD4S / XD4 Plus Firmware version 3.0.0.4.386_69095 (2024/11/18)
- Started by fruitcornbread
- Replies: 0
Latest threads
-
wrong foldername when get permission
- Started by dmr24
- Replies: 1
-
-
AX88U will only connect at 80Mhz
- Started by antik
- Replies: 3
-
QNAP Firmware 5.2.2.xxx Update destroys Login and Data- Started by PR3MIUM
- Replies: 1
-
Support SNBForums w/ Amazon
If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!
Sign Up For SNBForums Daily Digest
Get an update of what's new every day delivered to your mailbox. Sign up here!