I struggled with this problem for several years. I finally solved it by using an AiMesh network consisting of two identical ASUS routers (RT-AC68U) with a wired interconnection. https://www.asus.com/microsite/AiMesh/en/index.html
Now there’s an idea. Our hardware is a hodge-podge of different brands or different models from the same brand. No two are identical. If we upgrade the network, I’ll take this into consideration. Thanks for the tip.
This is a shot in the dark – but in your assortment of routers/APs, are they all providing DHCP and/or NAT themselves, or have you turned them all around so they just extend the base IP network from the router itself?
If your phone is getting a different IP address, or going through multiple layers of NAT each time you change APs, the application would have to create a new connection. If it always was the same IP address on the same network, then it would just be an interruption of the connection from which to recover, and it might handle it more gracefully.
Edit to explain further:
If the address/route changes, the RW application is probably going to retry some number of times on the old connection before giving up and trying a new connection. If the address/route remain the same, then one of those retries will eventually succeed, and it will simply pick up where it left off, saving you that retry/timeout cycle time.
It’s all one simple local network with the only NAT/DHCP happening at the primary router (we did have a router that did not turn off its DHCP server in AP-mode, but it was identified and removed). The IP address of the phone does not change between AP’s. The RW app, therefore, seems to require something staying static other than the IP address and SSID to remain connected to WiFi.
@isotope & @larsh,
Thanks for bringing up and ruling out something that could have been a cause of the problem.
I just went back and reviewed the entire conversation, hoping to find something else that I neglected to explore with you.
- You mentioned that the AP’s are connected to the main router by Ethernet
- Could you verify distance from main router to any AP doesn’t exceed the recommend the maximum recommended length for a Category 5e Ethernet cable, which is 100 meters, roughly 330 feet?
- I wouldn’t consider the ability to browse the Internet the best indicator of why the RW App should remain connected. RW has to consider the path both direction for latency, jitter, packet loss and MOS before the SIP connection is valid and the RW ARC is filled (levels documented here)
- Things I would explore further, if I were facing this problem, would be the Channel that each of the AP’s are using and the RSSI observed as you travel from building to building
I received this suggestion from one of our engineers. (Apparently I’ve failed as Community Manager to help my colleagues feel comfortable posting in our Community :.)
One idea would be to run the diagnostic tests from the APK when the member is in a funky state after transitioning buildings and calling/messaging isn’t working before resetting the connections. Share the diagnostics results someplace to look at later, like a draft email. Also, the assigned IP address gets mostly redacted upon the share, so touch “Show full logs” and write the full IP address somewhere.
And then reset the connections and run the diagnostics again, and save those results in the same way.
Assuming that there isn’t an obvious finding from the diagnostics on the main screen, compare the two saved results. Items to look at specifically would be “Is Active Data Network Cell”, the 3 pings (pass all 3 times?), the assigned IP address (same IP address both times?), “HTTP Connect for 204 using https”, “SIP Connected”, “MQTT connected”.
He also commented:
The SIP and MQTT connections are supposed to immediately re-establish a new connection to the server after a new network replaces the previous one (i.e., cell->wifi). It is possible Android’s doze mode may be impacting that.
@larsh et al,
The update that @southpaw recently added, points out a discussion from yet another engineer … I guess we will need to call him/her @Sue2 as SUE has already been claimed by ‘Some Unknown Engineer’ who was outed by @seniorgeek for his help in bringing the OnePlus7T to the RW world.
- The discussion with @SUE2 hinges around the use of the Diagnostics that can be seen here
- RW App/Settings/Advanced Settings/ Run diagnostics test
To be fair, you are up against engineers.
The diagnostic tests are something I’ve never used and are quite fascinating. I’m still playing around with them, but preliminary results show that the latency (900-1000 ms) and packet loss (60%?) tests are, obviously, failing when RW says it’s disconnected. I’ll update if I find anything more of interest.
All cables are indeed Cat 5e and less than 330 feet in length before reaching a switch or endpoint.
It never really sunk in before that RW might have to run tests prior to considering a WiFi connection for VOIP traffic. Interesting.
Oh, and if doze mode is the same thing as battery optimization in Android 10, RW is not battery optimized.
- I really can’t see where Doze would present itself in the manner you are seeing, but I long ago proved to myself that saying ‘never’ is not the best path
- I can’t speak to to Doze/Battery Optimization on 10.0, however just completed a re-test on my Moto X4 9.0 turning off the MacroDroid ‘fix’ published in Managing Doze Mode - (phone is on WiFi) calls via cell | calls go to voicemail | calls are missed
- This was after changing the Battery to NOT optimized resulted in the Republic Wireless to post the Notification: ’On Cell’ Calls over cell. No access to messages or voicemails. Check your network connection.
- This is the normal Trigger that the fix utilizes to turn on the display
- In all the testing I have done, the only thing I can say actually prevents my phone from going into Doze is having it plugged in, or turning on the display
After running a fair few tests over the past several weeks, it’s time for an update.
When running diagnostics where WiFi is connected but RW is not, the tests fail 95% of the time with the only casualty being as follows:
SIP Connected: FAIL: isVoipConnected=false isWifiConnected=true
Interestingly, the disconnect seems to only occur when moving back and forth between an AP and the WiFi of the main router (which is a Netgear R6700) and resolves itself after a few minutes. The disconnect does not happen when moving between AP’s. As such, perhaps replacing the central router would fix the problem. But I’m still confused as to what might be the root of the issue. We do have servers on the LAN that can be accessed through the main WiFi as well as through the AP’s, so the main WiFi is not segregated from the rest of the network.
I don’t know if my profile identifies me as this, but I’m an RW employee.
I have 7 APs in my house (3 in the 2.4 GHz band, 4 in the 5 GHz band), all with different SSIDs because, while handoffs between APs still work fine, this naming forces a re-association on every attachment. My DHCP server is at a centralized modem, just as you’ve stated. Since the DHCP process associates an IP address with the MAC address of the phone’s WiFi, the IP address doesn’t change. But, the different SSIDs forces Android to renew everything when you switch APs, even though the IP address doesn’t change.
You may want to identify the AP SSIDs with the location, as a simple way to force a re-association and renew the DHCP connection. That should fix the latency issue.
Thanks for chiming in, always good to hear from some of the folks behind the magic curtain
I am trying to understand your solution and have a couple of questions.
- With your 7 different SSID/Network names, what triggers the handover from on AP to the next as you traverse your house?
- Does a VoIP phone call continue un-interupted during the re-association process?
- With 7 Access Points, how do you prevent co-channel and/cross-channel interference?
- When you run the RW apps Diagnostics, what errors/warnings (if any) does it detect?
- What steps would @larsh need to take to “identify the AP SSIDs with the location” ?
Well @deant, it looks like that works. Simply renaming the central WiFi causes RW to reconnect instantly. It’s slightly annoying to have multiple logins for the same network, but it’ll make do until an upgrade takes place.
Thanks for asking, but I think @deant was just suggesting a naming scheme that includes hints as to where each AP is located on the premises.
As you now have it configured, I guess it is on the users to know when they need to login to the central WiFi?
Doesn’t this make it impossible to maintain connectivity as you go from bld to bld?
Yes, it does make it difficult to maintain connectivity. But the cool thing about cinder block and metal-lined walls is that they segment the WiFi networks rather nicely. So as you walk outside of one building, the phone loses WiFi and switches to cell. And as you approach the other building, it switches back to WiFi. So yes, a few seconds of WiFi downtime do exist, but that’s a lot better than a few minutes, and it happens when cell is the most accessible. Is the situation ideal? No, but it’s well within tolerance.
Yes, I did mean to simply change the SSID names to show where they’re located. My Android devices all store the AP passwords and the devices switch based upon signal strength/quality. So, it’s usually an automatic handover. I’m glad it worked for you. It’s hard to maintain connectivity with the APs located inside your type of buildings, so I understand that hard switch.
I didn’t see your question:
“With 7 Access Points, how do you prevent co-channel and/cross-channel interference?”
I have a frequency plan for my APs. If you notice, I mentioned that I have three in the 2.4 GHz band, one each on channels 1, 6, and 11 (all that are available). And, the four 5 GHz APs are all distributed throughout that band, so I have no issues. I’m a big fan of creating a frequency plan for any coordinated WiFi networks.
- Thanks for the feedback, the importance of proper WiFi network layout is something that cannot be emphasized enough.
- A plug for the RW Diagnostic (avail from the home page of RW App), this diagnostic will show users if co-channel and/cross-channel interference is present (usually caused by neighbors) … here is an example of a worst case scenario.