What's new

[Official Release] AiMesh Firmware v3.0.0.4.384.20308 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!

Anyone else have an issue with openvpn on this firmware? If I select to redirect lan and internet on a tap openvpn connect then the clients internet won't work. Never had this problem on merlinwrt... Also wish they would allow more than 1 openvpn server instance
I’ve been able to use the OpenVPN client directly on the router itself
 
WPS is not as secure as you think, and rule of thumb, disable/block all the stuff not need for better security/control
 
WPS is not as secure as you think, and rule of thumb, disable/block all the stuff not need for better security/control
Definitely....and time to eat some crow.

Got some time to do some pen testing and it appears that Asus does allow for pin based WPS and it is turned on all the time if you have WPS enabled. They have however implemented some safeguards so that if you try an invalid pin a number of times it will put the AP into locked mode where it will not allow for anymore attempts which would make a brute force attack pretty difficult (not impossible, especially if they are doing this by mac address). Your best option at this point is to just turn it off with the nvram commands and just enable it when you need it.
 
I think the discussion around WPS has ran its course folks. Asus has already explained where they stood at this time regarding AiMesh's implementation, time to move on until something changes on their end. Please start a separate thread if you want to further debate the (in)security of WPS as a technology.
 
I think the discussion around WPS has ran its course folks. Asus has already explained where they stood at this time regarding AiMesh's implementation, time to move on until something changes on their end. Please start a separate thread if you want to further debate the (in)security of WPS as a technology.
Last time I checked this was an Aimesh firmware specific thread. The issue we are discussing is specific to Aimesh. Asus had said that they didn't think WPS was always active but that is not the case if you have Aimesh nodes. I think letting folks know that there is a security risk, albeit a small one, and how to mitigate that risk is wholly appropriate for this thread.
 
Definitely....and time to eat some crow.

Got some time to do some pen testing and it appears that Asus does allow for pin based WPS and it is turned on all the time if you have WPS enabled. They have however implemented some safeguards so that if you try an invalid pin a number of times it will put the AP into locked mode where it will not allow for anymore attempts which would make a brute force attack pretty difficult (not impossible, especially if they are doing this by mac address). Your best option at this point is to just turn it off with the nvram commands and just enable it when you need it.
most router will protect by brute force attactk but not the newest method, don't want to discus the details here, I had test that new method on some other router, but no time to test on my ac68u and I prefer just disable it, even I will lost the aimesh function.
 
Definitely....and time to eat some crow.

Got some time to do some pen testing and it appears that Asus does allow for pin based WPS and it is turned on all the time if you have WPS enabled. They have however implemented some safeguards so that if you try an invalid pin a number of times it will put the AP into locked mode where it will not allow for anymore attempts which would make a brute force attack pretty difficult (not impossible, especially if they are doing this by mac address). Your best option at this point is to just turn it off with the nvram commands and just enable it when you need it.
Thank you for testing. I've been busy all day and haven't had a chance to go digging for old WPS equipment, so I appreciate the update, and even more so in the context of "eating crow." I'm not thrilled with the result, but this is not entirely surprising to me, based on everything I've read so far. The important thing is, we now know 100% that WPS PIN option is enabled at all times on the node, by default, and can only be switched off using the NVRAM in SSH/telnet. Even with the lockout (which, per my research is pretty common now as a counter measure to "secure" WPS), it's still a threat. Out of curiosity, do you know how many attempts it took to lock out and/or how long you had to wait between tries? I assume you had to reset the node/router to attempt another WPS?

Last time I checked this was an Aimesh firmware specific thread. The issue we are discussing is specific to Aimesh. Asus had said that they didn't think WPS was always active but that is not the case if you have Aimesh nodes. I think letting folks know that there is a security risk, albeit a small one, and how to mitigate that risk is wholly appropriate for this thread.
Yup. That was kind of my point all along. It's directly related to this firmware (and likely every firmware with Aimesh prior and likely with the new one, though I haven't yet updated). Now we know it actively functions with the router set to WPS off, but we don't know why it does this. Is it necessary to maintain Aimesh? I know in general WPS is *not* required to set up nor maintain a mesh, as many other systems apparently do not even support any form of WPS. So it's not a mandate for the network, but may be part of how Asus has chosen to implement Aimesh.

Given the above, I would hope @arthurlien can comment on this in a more definitive manner. Is this a design requirement for Aimesh to function properly, or is it an honest to god security-related bug in the implementation of the system? I can't see how it's the former, as turning it off at the NVRAM level doesn't seem to negatively impact the system (from what others have reported), so if it's indeed the latter, will this be patched in a future firmware?

This is a security threat, albeit minor, that most people who will be using Aimesh may never pick up on, even if they're aware enough to turn off WPS at the router. Thank you again to @RandomName23 for taking it upon himself to double check and report back. I am most appreciative of this community for working this one through.
 
Last edited:
Last time I checked this was an Aimesh firmware specific thread. The issue we are discussing is specific to Aimesh. Asus had said that they didn't think WPS was always active but that is not the case if you have Aimesh nodes. I think letting folks know that there is a security risk, albeit a small one, and how to mitigate that risk is wholly appropriate for this thread.

My point is that the discussion is running around in circles.
 
My point is that the discussion is running around in circles.

... probably looking for an authoritative/credible/non-dismissive response such as, 'yes, this firmware version does not yet function as advertised... disabling WPS does not actually disable WPS as is accurately indicated by a popular WiFi signal analyzer app... and attempting to disable WPS does not actually break AiMesh... at this time.'

Such a forthright response could have easily been overlook here... and sometimes end users participating in a manufacturer's online user community must read between the lines to know what has not been represented, and then shut up or risk running around in circles through no fault of their own.

Me, I would have simply annotated, disabled, and/or removed the WPS tab from the firmware until it actually works with AiMesh instead of officially releasing a function that I know does not work yet. Or else be prepared to entertain my customers running around in circles and not tell them to shut up.

OE
 
... probably looking for an authoritative/credible/non-dismissive response such as, 'yes, this firmware version does not yet function as advertised... disabling WPS does not actually disable WPS as is accurately indicated by a popular WiFi signal analyzer app... and attempting to disable WPS does not actually break AiMesh... at this time.'

Such a forthright response could have easily been overlook here... and sometimes end users participating in a manufacturer's online user community must read between the lines to know what has not been represented, and then shut up or risk running around in circles through no fault of their own.

Me, I would have simply annotated, disabled, and/or removed the WPS tab from the firmware until it actually works with AiMesh instead of officially releasing a function that I know does not work yet. Or else be prepared to entertain my customers running around in circles and not tell them to shut up.

OE
Personally, I'd like to see them acknowledge the problem, rather than just saying "you need to push the button" and "your wifi scanner is just telling you it supports WPS, not that it is active," both of which have proven to be false at this point.

If it's going to stay the way it is, people need to know it is broken to prepare accordingly (of which there is an unofficial fix in this thread). If they're going to officially fix it in future release, all we need is confirmation that they're looking into it, so we can be on the lookout for the appropriate update. Not acknowledging a demonstrated security problem is poor support all around.

The WPS conversation up to this point has been basically me asking "are you sure it's not broken?" and everyone going "it's fine" until, lo and behold, it isn't. We just got that confirmation from a member yesterday, and now we're awaiting some kind of acknowledgment from Asus that they understand the problem and what, if anything they're going to do about it.

Most everyone here is more technically literate than your average person, I would assume. But Asus has a responsibility to the bulk of their consumers to make sure things work as they intended out of the box for those that may not be able to figure out what's going on. There are certain responsibilities individuals need to assume themselves (e.g., updating firmware), but if a switch says something is off and it's not, that is on Asus, and they should fix it or explain plainly and clearly why it works the way it does. That's where we are now.
 
That's where we are now.

ASUS is free to do whatever they want. I would leave it at that and look forward to the next release. :)

OE
 
I don't know it is a bug or anything else, at least Aimesh still work for me when wps disable on all node, I am using ethernet as backhaul so I don't care will that affect wifi backhaul or not. I guess wps is used for node setup
 
Naturally. But I would hope they'd address it. It would be the responsible thing to do.

We've already covered 'hope' and 'wait' and 'trust'. If that's not sufficient, start another topic... but don't expect much discussion about it because the normal redress is to take your money elsewhere, not argue personal expectations.

You've made a worthy point; don't belabor it.

OE
 
I don't know it is a bug or anything else, at least Aimesh still work for me when wps disable on all node, I am using ethernet as backhaul so I don't care will that affect wifi backhaul or not. I guess wps is used for node setup

At this point, my assumption and experience is that WPS is only required for adding nodes. After that, disabling WPS does not appear to upset the AiMesh.

OE
 
Quick question in regards to bandwidth with wireless backhaul - I have 2 AC68U's, one as main and one as node. I have a Tx and Rx of around 870M on the 5GHz band and around 260 for both Tx and Rx on the 2.4GHz band in regards to the connection from the main to the node. I get roughly 350/25 through my ISP, and I achieve those speeds when wirelessly connected to the main, but I cannot get beyond ~220Mb when connected to the node. If I hardwire a PC to the node I do get the full speeds however. My question is - if I replace the main with something like the AC86U, would I be able to achieve full speeds through the node when connected wirelessly? Or is it still bottle-necked? Thanks.
 
Quick question in regards to bandwidth with wireless backhaul - I have 2 AC68U's, one as main and one as node. I have a Tx and Rx of around 870M on the 5GHz band and around 260 for both Tx and Rx on the 2.4GHz band in regards to the connection from the main to the node. I get roughly 350/25 through my ISP, and I achieve those speeds when wirelessly connected to the main, but I cannot get beyond ~220Mb when connected to the node. If I hardwire a PC to the node I do get the full speeds however. My question is - if I replace the main with something like the AC86U, would I be able to achieve full speeds through the node when connected wirelessly? Or is it still bottle-necked? Thanks.

Great details, much appreciated... thanks! I would also like to know the node-to-node distance, intervening building materials, and general amount of neighboring 2.4 GHz WiFi present.

Given your very good 5.0 backhaul rates, I wonder if your not so bad 2.4 backhaul rates indicate some interference on that band. Did you use a signal analyzer app to assess ambient 2.4 signals and then set your 2.4 band to the least used channel 1,6, or 11 at 20 MHz? Also, these rates seem to vary with antenna formation and traffic... perhaps you were reporting your max rates observed.

The full ISP speed when the client is wired to the node suggests the wireless backhaul is good/great, and perhaps suggests the client wireless connection is not as good at the node as it is at the router.

My feeling is that your rates are respectable and expected, and your lessor rate at the node could be due to wireless backhaul overhead or maybe a lessor wireless connection between the PC and node... it is in a different location and may have more ambient interference that might lower the PC-to-node WiFi throughput.

More observations might help narrow it down. Did you notice the client's wireless properties/speed of connection at router and at node?

I would not be quick to upgrade just your router to a higher spec for perhaps marginal or no affect. I would give it more trial. Eventually, we all want to upgrade and re-deploy (the AiMesh promise) in due time. Of course, if you need more nodes now, do it and let us know the results! My gut feeling is that the 68U is good enough for a simple AiMesh.

Perhaps others will weigh in with more/better advice.

OE
 
Last edited:
Quick question in regards to bandwidth with wireless backhaul - I have 2 AC68U's,

I have 2 68U nodes (off one 86U main router) - one wired and one wireless. My wireless 68U is dreadful. A client wired into the wireless node is fine, but wireless clients have hugely variable speed, often going to zero. I have swapped hardware around and it's not that, and the only wifi signals around here are from me.

I'd wait to see if the firmware is improved. I found that you can improve stability and speed by disabling Roaming Assistant.
 
I have 2 68U nodes (off one 86U main router) - one wired and one wireless. My wireless 68U is dreadful. A client wired into the wireless node is fine, but wireless clients have hugely variable speed, often going to zero. I have swapped hardware around and it's not that, and the only wifi signals around here are from me.

I'd wait to see if the firmware is improved. I found that you can improve stability and speed by disabling Roaming Assistant.

My install notes detail my AiMesh with two 68Us. My wireless client at the node gets steady and near full ISP speeds over a wireless backhaul that is probably near reasonable limits... nothing dreadful. I would find 'hugely variable' and 'going to zero' to be unacceptable performance.

https://www.snbforums.com/threads/o...-supported-products.44375/page-14#post-381537

OE
 
Great details, much appreciated... thanks! I would also like to know the node-to-node distance, intervening building materials, and general amount of neighboring 2.4 GHz WiFi present.

Given your very good 5.0 backhaul rates, I wonder if your not so bad 2.4 backhaul rates indicate some interference on that band. Did you use a signal analyzer app to assess ambient 2.4 signals and then set your 2.4 band to the least used channel 1,6, or 11 at 20 MHz? Also, these rates seem to vary with antenna formation and traffic... perhaps you were reporting your max rates observed.

The full ISP speed when the client is wired to the node suggests the wireless backhaul is good/great, and perhaps suggests the client wireless connection is not as good at the node as it is at the router.

My feeling is that your rates are respectable and expected, and your lessor rate at the node could be due to wireless backhaul overhead or maybe a lessor wireless connection between the PC and node... it is in a different location and may have more ambient interference that might lower the PC-to-node WiFi throughput.

More observations might help narrow it down. Did you notice the client's wireless properties/speed of connection at router and at node?

I would not be quick to upgrade just your router to a higher spec for perhaps marginal or no affect. I would give it more trial. Eventually, we all want to upgrade and re-deploy (the AiMesh promise) in due time. Of course, if you need more nodes now, do it and let us know the results! My gut feeling is that the 68U is good enough for a simple AiMesh.

Perhaps others will weigh in with more/better advice.

OE

Wow! Thank you for such and in depth analysis of my scenario! My main and node are ~30-40ft away from each other, the main being one floor below. I decided to swap them and start fresh, to see if the results would change. After the initial setup of the node, which recommends a distance of around 6ft during syncing/setup, I connected my iPhone X to the node. The Rx and Tx rate on the 5GHz band was reporting at 1200M, so plenty of bandwidth. I was still only able to pull ~250Mb, which is a hair better than when the node is setup in its actual location. This tells me that there is something restricting the AC68U, even when both main and node are essentially right next to each other. I analyzed my surrounding neighbors, and both my 2.4 and 5 bands are on their own channels. Not sure what else to change/test as far as settings are concerned.
 

Latest threads

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!
Top