ASUS RP-AC56 1200mbit extender completely not working in AP mode?

[dev-jam]

Dev-jam: I'm in the US and I picked up the repeater and I'm having issues with the US version as well. I saw you posted the Asus response. Any chance you could ask Asus some follow up questions: how can things be working within the norm when the product shipped with a firmware that is no longer available on the Asus support site after problems were reported? Why was it taken down? Is normal behavior with the currrent firmware listed on the support site (which means we should roll back)?

If you are unable to re-open the case or re-open dialog with the Asus you are working with, I will try to open an Asus support case myself. Thanks.

Hi Heckler,

I was starting to accept the issue for now but now it's getting real strange!
(for Asus products that is because so far I've only had excellent experience)

I'm in the Netherlands and my units came with firmware: 3.0.0.4.378.6655
What version did your device come with?

My case was closed. I did refer to this thread because in the initial response Asus advised that they have had running RP-AC56's in the test lab without problems.

Unfortunately I haven't seen a response in this thread of the other users that have contacted Asus.

Guess it is a good idea if you open a support request. Not always the news you hope for but they are very responsive. You could even refer to my Case ID at Asus. ID=RTM20160124200293-213

will keep an eye on this thread!

 

[Heckler Koch]

My unit came with firmware: 3.0.0.4.378_6717-g14c8d38. I thought you may have the same. The version on the website is what you have and the version I have is nowhere to be found. But I am using mine in repeater mode. I'm going to try different modes and play around with it some more before I open a case.

 

[swedemike]

A rather useless/unambitious response. It is obvious that IF this is normal behaviour, it is a rather poor device.

It is basically impossible for me to move around in the house while using a device. As soon as I loose the connection there is this delay for several minutes. Even if trying to disconnect/connect manually I get the same issue, so I don't but the ASUS explanation.

Also when turning on previously sleeping devices in different rooms I seem to get the same behaviour (but it could be that they keep the connection in some way I don't understand).

Luckily I seldom move around that much while using the device, or in much of a hurry at home so I will live with it for now.

I wouldn't recommend the device to anyone though, until ASUS recognises the issue and fixes the firmware. MAYBE it works better in other modes than AP, but wouldn't take my chances.

Asus response:
<<
Our R&D department came with the conclusion after testing and checking the case thouroughly. That this is normal behavior for the device. The full reason as below:

<<

 

[dev-jam]

A rather useless/unambitious response. It is obvious that IF this is normal behaviour, it is a rather poor device.

It is basically impossible for me to move around in the house while using a device. As soon as I loose the connection there is this delay for several minutes. Even if trying to disconnect/connect manually I get the same issue, so I don't but the ASUS explanation.

Also when turning on previously sleeping devices in different rooms I seem to get the same behaviour (but it could be that they keep the connection in some way I don't understand).

Luckily I seldom move around that much while using the device, or in much of a hurry at home so I will live with it for now.

I wouldn't recommend the device to anyone though, until ASUS recognises the issue and fixes the firmware. MAYBE it works better in other modes than AP, but wouldn't take my chances.

Hej SwedeMike,

I was about to accept the fact that the behaviour is 'by design' and get some other AP's.
Did a final test which does not match with the Asus explanation.
Reopened the case.

Background of my test:

My interpretation of the answer of the R&D department:

- If a client roams to another AP the old AP will keep trying to keep the connection open before removing it from its association list
- The new AP (in this case also and RP-AC56) will not handle traffic for the newly connected client since it is aware that the old AP still keeps the option open that has temporarily lost the connection

This seems like a perfectly logical explanation (but not the best solution for an AP)
Not 100% sure but according tho the log the AP's are indeed aware of their coexistence
snippet from the RP log:
Feb 14 16:12:01 kernel: ACT - SendBSS2040CoexistMgmtAction(BSSCoexist2040=0x4)

to get a better roaming experience I tried the following:

- In the WiFi Professional settings I enabled Roaming assistance and measured wifi signal strength throughout the house to find 'break even point
- On the client side (Intel NIC) I configured the driver options to:
Roaming Agressiveness - 1. Lowest


If I understand it correctly this would mean that:
- the AP would take the 'lead' in ending the association
- Client would look for strongest signal and reconnect to that one that's strongest

Since in this case the first AP would already be disassociated a normal connection would be established with the new 2nd AP.


Unfortunately this didn't happen either.
Tried different Roaming Assistance settings (up to -40db) but the behaviour is still the same.

This is maybe a separate issue that I hope you can confirm or provide pointers where I'm going wrong.


I could imagine that the 5 mins. disconnect problem could also easily be solved by using the following algorithm (feature request).
1. Client connects to new AP (roaming)
2. New AP sends update to the 'old' AP that a client connected
3. Old client sees that it's still in it's association list and removes it.

Will keep everyone posted on the response.

 

[L&LD]

Hej SwedeMike,

I was about to accept the fact that the behaviour is 'by design' and get some other AP's.
Did a final test which does not match with the Asus explanation.
Reopened the case.

Background of my test:

My interpretation of the answer of the R&D department:

- If a client roams to another AP the old AP will keep trying to keep the connection open before removing it from its association list
- The new AP (in this case also and RP-AC56) will not handle traffic for the newly connected client since it is aware that the old AP still keeps the option open that has temporarily lost the connection

This seems like a perfectly logical explanation (but not the best solution for an AP)
Not 100% sure but according tho the log the AP's are indeed aware of their coexistence
snippet from the RP log:
Feb 14 16:12:01 kernel: ACT - SendBSS2040CoexistMgmtAction(BSSCoexist2040=0x4)

to get a better roaming experience I tried the following:

- In the WiFi Professional settings I enabled Roaming assistance and measured wifi signal strength throughout the house to find 'break even point
- On the client side (Intel NIC) I configured the driver options to:
Roaming Agressiveness - 1. Lowest


If I understand it correctly this would mean that:
- the AP would take the 'lead' in ending the association
- Client would look for strongest signal and reconnect to that one that's strongest

Since in this case the first AP would already be disassociated a normal connection would be established with the new 2nd AP.


Unfortunately this didn't happen either.
Tried different Roaming Assistance settings (up to -40db) but the behaviour is still the same.

This is maybe a separate issue that I hope you can confirm or provide pointers where I'm going wrong.


I could imagine that the 5 mins. disconnect problem could also easily be solved by using the following algorithm (feature request).
1. Client connects to new AP (roaming)
2. New AP sends update to the 'old' AP that a client connected
3. Old client sees that it's still in it's association list and removes it.

Will keep everyone posted on the response.

Pretty sure you have that understanding backwards.

Set roaming aggressiveness to highest and test again.

The client is what roams, not the router.

 

[dev-jam]

Pretty sure you have that understanding backwards.

Set roaming aggressiveness to highest and test again.

The client is what roams, not the router.

I really wish I mixed up the values for roaming aggressiveness
Did a double check to be absolutely sure. Straight from the Intel website: http://www.intel.nl/content/www/nl/...85.html?_ga=1.230039516.1336262409.1455557812

Roaming aggressiveness

This setting allows you to define how aggressively your Wi-Fi client roams to improve connection to an access point. Click Use default value to balance between not roaming and performance.

• Lowest: Your wireless client will not roam. Only significant link quality degradation causes it to roam to another access point.
• Medium-Low/Medium-High: Allow Roaming.
• Medium: Balanced setting between not roaming and performance.
• Highest: Your Wi-Fi client continuously tracks the link quality. If any degradation occurs, it tries to find and roam to a better access point.

--------
Indeed normally it's the client that initiates roaming.
That's what the 'Roaming Assistance' feature should do in the AP. Move the initiative to the AP.


Got a reply from Asus:

>>
Thank you for your email.

With the roaming option you can change the threshhold for when it has to change between product. This however doesn't influence the time it takes to change between them.

According to our R&D it takes such time due to multiple checks and switching of the product.

<<

 

[L&LD]

I really wish I mixed up the values for roaming aggressiveness
Did a double check to be absolutely sure. Straight from the Intel website: http://www.intel.nl/content/www/nl/...85.html?_ga=1.230039516.1336262409.1455557812

Roaming aggressiveness

This setting allows you to define how aggressively your Wi-Fi client roams to improve connection to an access point. Click Use default value to balance between not roaming and performance.

• Lowest: Your wireless client will not roam. Only significant link quality degradation causes it to roam to another access point.
• Medium-Low/Medium-High: Allow Roaming.
• Medium: Balanced setting between not roaming and performance.
• Highest: Your Wi-Fi client continuously tracks the link quality. If any degradation occurs, it tries to find and roam to a better access point.

--------
Indeed normally it's the client that initiates roaming.
That's what the 'Roaming Assistance' feature should do in the AP. Move the initiative to the AP.


Got a reply from Asus:

>>
Thank you for your email.

With the roaming option you can change the threshhold for when it has to change between product. This however doesn't influence the time it takes to change between them.

According to our R&D it takes such time due to multiple checks and switching of the product.

<<

Okay.

We're reading the same thing but understanding totally opposite.

I still think you need to try Highest instead. Won't hurt to confirm if this fixes anything for you at least.

 

[dev-jam]

Okay.

We're reading the same thing but understanding totally opposite.

I still think you need to try Highest instead. Won't hurt to confirm if this fixes anything for you at least.

Roaming aggressiveness is the setting for the Client driver (Intel WiFi NIC)
Roaming assistance is the setting in the Accesspoint

Tried the opposite but didn't work either (Roaming aggressiveness in client -> high, Roaming assistance on AP's turned off)

I have received a response from Asus support that it's a current limitation but R&D sees this as an issue that they couldn't confirm will / can be fixed in a future update.

Suggested to put it to problem management / product development.

In the mean time I've spent way too much time on this one.
Looking for a different set of AP's.
Netgear EX6150 has a similar form factor and simplicity. Will make sure I have a confirmation that these are a bit better on roaming!

 

[L&LD]

Roaming aggressiveness is the setting for the Client driver (Intel WiFi NIC)
Roaming assistance is the setting in the Accesspoint

Tried the opposite but didn't work either (Roaming aggressiveness in client -> high, Roaming assistance on AP's turned off)

I have received a response from Asus support that it's a current limitation but R&D sees this as an issue that they couldn't confirm will / can be fixed in a future update.

Suggested to put it to problem management / product development.

In the mean time I've spent way to much time on this one.
Looking for a different set of AP's.
Netgear EX6150 has a similar form factor and simplicity. Will make sure I have a confirmation that these are a bit better on roaming!

Well, it's good that you gave it a try. Hope the next set works well for you.

However, it is not just the AP's that need to be up to snuff, the clients need to be there too.

 

[dev-jam]

Not sure if this thread is still active but wanted to let everybody know I returned my RP-AC56's and replaced them with 2 Netgear EX6150's.
Works great! feels unreal to be able to walk through the house again and have a seamless hand-over.
As a usability test I had 2 full hd stream on both my laptop and smartphone running.
No issue at all.
15 minutes setup (including update to latest firmware)

Hope this helps in case you have or are looking for the same setup (2 Wall Wart AC1200 simultaneous dual-band AP's)

 

[jevel]

Hej SwedeMike,
*snip*
Not 100% sure but according tho the log the AP's are indeed aware of their coexistence
snippet from the RP log:
Feb 14 16:12:01 kernel: ACT - SendBSS2040CoexistMgmtAction(BSSCoexist2040=0x4)

This tells you that is has detected another wifi signal in its own channel, and that it is supporting coexistence extensions. This will happen no matter what it finds as long as it supports these standards.

*snip*

I could imagine that the 5 mins. disconnect problem could also easily be solved by using the following algorithm (feature request).
1. Client connects to new AP (roaming)
2. New AP sends update to the 'old' AP that a client connected
3. Old client sees that it's still in it's association list and removes it.

Will keep everyone posted on the response.

This behavior would warrant some sort of controller emulation with timing support and advanced control mechanisms. That would of course sort things, but sadly this is at least currently available mostly in the enterprise class equipment. Don't hold your breath waiting for it to enter sub $1000 equipment.

As for waiting for ASUS to sort things, I'd just buy something else. I have been waiting for a fix for using my RT-AC68U as a media bridge on my RT-AC87U since November. Not as much as an update neither through these forums or through official support channels in Norway.

ASUS - good products when they work. Support for the demanding customer? Not so much.

-KJ

 

[JacquesB]

Now the 2 new RP-AC56 I realized that no clients could connect thru them.
In general no clients can get on to my WIFI network through these ones and/or they are connected but get no IP.

Hello, All. I'm afraid my information casts further doubt on ASUS' ability to master AP Mode in their products. I have the exact problem described by Peter (the OP), wireless clients either not associating with the AP or not being able to get an IP address from the main router's DHCP via the AP, but here are a few specific differences in my situation (that make the issue seem even more generalized that what's described in this thread):

(1) I'm in the USA with all USA-purchased ASUS equipment.
(2) My main router is the RT-AC68W (the "W"hite version of the better known RT-AC68U, but identical except for color).
(3) The extender I'm trying to use in AP Mode is the newly released RP-AC68U (have you seen this beauty?! It's a 7"x4"x4" black monolith with Mayan-inspired red LED accents when it's powered on, 3x4 internal antenna array, AC1900 classification). Needless to say it's running the factory firmware, it being the one and only version available.
(4) AP Mode is explicitly supported with this device (even though it's mostly marketed as an extender).
(5) It does not even have a DHCP service feature, so there's no way it's interfering with the main router's DHCP.
(6) So, to briefly describe my configuration, the AP is connected via (known-good) Ethernet cable from an Ethernet port on the main router to the first Ethernet port on the AP (the AP has no WAN port, so no mistake possible there either). The AP is assigned a static IP address outside the main router's DHCP scope (close to the router's own IP address). I have, in the course of troubleshooting this issue, tried many WiFI configs: same SSIDs as the router's (there are two, one for 2.4GHz and one for 5GHz), different SSIDs, beamforming turned on and off, long and short preamble, etc... but no luck: some WiFi devices appear unable to associate with the AP (they seem to give up too quickly for it to be a DHCP issue), others appear to associate but eventually give up when they can't get an IP address (even though almost all of them have explicit IP reservations in the main router's DHCP configuration).

I will be opening a case with ASUS and will (eventually) report anything useful. In the meantime, this thread has given me some ideas, like being more patient (maybe there is something to that 5 minute business), and maybe try removing some of those DHCP reservations (maybe the main router doesn't like giving the same IP address to the same MAC address suddenly coming to it indirectly via the AP?? -- of course, MAC address spoofing is not an option with most devices, so I'll stay away from that).

Thank you all for your input so far. Very enlightening.

Jacques.

 

[JacquesB]

I've received a response from Asus [...] The reason why RP-AC56 takes 5 minutes to switch the connection is because the thorough algorithm behind it. The process as following:
1. AP makes inquiries to each client every 30 seconds see whether there are any packets to transmit.
2. Makes inquiries 3 times in a row, if there’s no packets to transmit
3. Kick out the client
4. Clients has to re-establish the connection with own profile
5. Connection established.
Therefore, it might take longer to re-establish the connection between RP-CA56<<

Is it just me or is that "explanation" nonsensical?! I can only hope for our sake as users of ASUS products that it's a reflection of a language barrier rather than technical abilities:

I don't see a necessity for any sort of timeout or "thorough algorithm": from the main router's standpoint, if a previously (Wifi-)associated MAC address suddenly appears as the source address of a packet on one of the Ethernet ports (as must be the case if the client associated with a separate AP), then the router should immediately consider the Wifi association terminated and start servicing the client via the Ethernet port. Same thing with DHCP: if a request comes in from a MAC address that currently has a valid lease (regardless of whether via Wifi or Ethernet), treat it as a renewal request and offer the same IP address immediately.

It's the same process as occurs (very quickly) when a device previously plugged into one Ethernet port is moved to a separate switch plugged into a different Ethernet port -- the router (even an ASUS) immediately updates its MAC table accordingly. An AP is really just a slightly different kind of switch plugged into an Ethernet port on the main router, one that accommodates both hard-wired Ethernet clients and Wifi-associated clients (virtually wired!)

Jacques.

 

[JacquesB]

I have an update on my situation with the RT-AC68W/RP-AC68U (router/AP) combination: after going back to having *different* SSIDs on the AP and following the advice in this thread to be patient when switching a Wifi device from the original router to the new AP (5 to 10 minutes in each case), every device was able to eventually (1) associate with the AP, (2) obtain an IP address from the router's DHCP service, and (3) successfully communicate with the rest of the network and the Internet. Note that these three events did not occur simultaneously but gradually over the span of those several minutes. Once a device is fully working with the AP, it'll reassociate with the AP on subsequent restarts without any delay.

This all means that the real issue is with the handover of a device from the router to the AP (and maybe vice versa -- I haven't wanted to test that yet since the devices are all working now), which further means that using identical SSIDs and hoping for the ability to roam between APs is for the moment impossible. I'll update the case I opened with ASUS with this information and see if I get the same "it's by design / thorough algorithm" response.

Jacques.

 

[JacquesB]

Another update: I have provided ASUS with the observation that, upon further experimenting, the issue (having to wait about ~10 minutes for full functionality) only exists when attempting a device handoff from the router to the AP. I can go back to the router without delay, but coming back to the AP again is another ~10 minutes wait.

The ASUS response so far is pretty generic but encouraging in the sense that they do not challenge the existence of an issue. Their exact words: "Our Engineering team will review, update the firmware and the associated issues will be addressed" -- can't ask for more than that!

Jacques.

 

[smokinfish]

Hi All - First time poster. I actually joined this forum just to chime in on this subject.

I recently purchased a Asus RT-AC5300 router to replace my airport extreme. I was hoping for better coverage in my 1800 sq ft, one story, 1927 Craftsman house with a detached garage. Unfortunately it didn't do the trick. The walls of the house have the original .5" thick planks underneath the plaster board. The kind of wood that will tear up a rotozip blade! The back two rooms are additions. So its basically a wifi eater. To remedy this I purchased two of the new RP-AC68U repeaters to use as Access Points. Unfortunately, I burned up an entire weekend trying to solve my AP connection problems before I found this thread.

Basically I found exactly what JacquesB is saying. That jumping from the Router to AP takes 5 - 10 minutes. Once connected the speeds are great, 10-15 mbs faster then in repeater mode.

If I turn off the wifi on my iPhone while connected to the AP and then connect back to the AP its connects quickly. Going from AP to Router is also fast. Its just the jump from Router to AP that makes roaming impossible. Its also creating all kinds of havoc when I am trying to connect my smart home equipment to the AP. They've all timed out way before they can reach a connection. This weekend I will try hard resets on the smart home devices and connect to the AP first.

This has been extremely disappointing considering the amount of $$$ I have spent on the ASUS equipment. The roaming feature being the number one reason for the purchase. They advertise it everywhere. Wrongfully so.

So now I am stuck. For the price of the repeaters I could buy another wifi router. Would that work better? Could I just run two routers with the same SSID and roam that way?

Currently I am running different SSID's on the router and AP's for trouble shooting purposes. When I had the router and AP's SSID the same it didn't work well at all.

UGH!!!

 

[JacquesB]

Hello, smokinfish. I wouldn't give up on ASUS and the RP-AC68Us just yet -- it's a brand new device, probably released prematurely, and the firmware is going to have to catch up with the promised feature set. I have a case open with ASUS (ASUS CASEID=RTM20160308204006-544 if you'd like to reference it with them at some point) -- they seem to understand the issue as described (your experience is *identical* to mine) and at no point did they deny its existence (remarkable for any tech support organization) -- they just say their engineers are working on it and will release firmware to fix it (no timeframe given). In the meantime, you should be able to get all your "static" (non-roaming) devices functional on the closest AP's alternate SSID (including the router's if it's closest) and pick one that works best overall for each one of your roaming devices.

By the way, the strategy that's worked well for me to get any device working with the AP is to select the AP's SSID as the preferred one for the device, and then soon turn off the device entirely while it's struggling in vain to fully associate with it. Wait 10-15 minutes (to get over that mystery hump), then turn the device back on -- it should immediately associate with the AP and get full network access. [If you can turn off the device's WiFi antenna, that's a good alternative to turning it off entirely].

Good luck (to us all).

Jacques.

 

[sfx2000]

I recently purchased a Asus RT-AC5300 router to replace my airport extreme. I was hoping for better coverage in my 1800 sq ft, one story, 1927 Craftsman house with a detached garage. Unfortunately it didn't do the trick

Because --- Physics!

Those older homes, they're pretty robustly constructed, eh? That's why they're still standing, and that's a plus in my book!

5GHz - no matter how many radios, is only going to go so far... best thing, whether it's the AC5300 or your older Airport Extreme - move the router to where folks work/play - and it might be using one AP/Router just for routing/WAN access, and another as a Wireless AP using ethernet/homeplug/MOCA...

 

[Kyse]

I have the same issue. My FIOS quantum router serves DHCP, the RT-AC68U in AP mode as my main AP (connects just fine, never had an issue), then I added the RP-AC68U AP and experienced the same lag to connect. In fact it got so bad (waiting 5-10 minutes is unacceptable), I called ASUS. They had me send it in as an RMA yesterday.

I guess after reading this thread I wasted money on packaging, because if this is an ongoing issue over other AP models, I predict they aren't going to resolve the issue and will just send me back the item saying it worked for them. I should have just dropped the cash on another RT-AC68U, it has stronger beaming/better range, costs the same, you can use the mobile app to connect to it even in AP mode (yet not the RP-AC68U even though it uses the same software), and I know AP mode works on it.

 

[JacquesB]

I wouldn't necessarily assume that another RT-AC68U would work any better: yes, it works as a (standalone) AP, as the RP-AC68U does "in a vacuum", but the issue is the *handoff* from one to another, and it may very well be that it would also happen between two RT-AC68U. In fact, I'm still not convinced that the RP-AC68U is solely at fault here: maybe the RT-AC68U shares some of the blame for somehow not "releasing" a Wifi client fast enough (whatever that might mean) or interfering with its immediate re-association with a different AP. I do find it interesting that you have the issue despite DHCP not being managed by the RT-AC68U -- that eliminates the DHCP component of the RT-AC68U as being at fault for not immediately re-issuing an address to a client moving from the "RT" to the "RP", which was one of the possibilities I considered.

I'm sorry you fell for the old RMA dodge! That's just Support throwing a case in the direction of Service to get it off their plate. Maybe e-mail them an update referencing my case # above so they put the matter in the right hands rather than butcher your device.

Jacques.