WiFi Roaming Failure

[Braehead]

I have multiple APs on my network, probably around 10. There is a common SSSID/Password combination for these to allow IoT devices to roam around my network. Basically to set up a device in my lab, and then be deployed to a applicable location and reconnection is automatic using the common SSID/Password pairing.

BUT, openHASP appears to be re-attaching to the BSSID, not the entered SSID/Password pair. So it is not possible to roam the device. It has to be wiped, reflashed and the SSID/Password pair re-added for the new AP.

I don't think this is the correct way for the WiFi to reconnect. I have not raised this as a bug for the time being as I would like some input regarding this first. Is this by design or accident? I now have several openHASP based units in my lab that I can't deploy as they won't connect outside of the original AP.

[nagyrobi]

Mines do roam, I have 3 UniFi APs. However I set my wifi data in user_config_override and build my own binaries so my plates connect automatically on first boot, no need to set up that part.

[Braehead]

Sorry, not viable to me. I only have 4 identical devices and I would like to use stock firmware. Quite happy to set them up individually. But the BSSID appears to be the reconnection details, not the SSID, as it should be.

Is there a difference if a user configuration is applied, compared to a portal defined credentials? Valid investigation path. I don't really have time to explore this path at the moment. But happy to perform other tests.

[fvanroie]

The user_config_override only changes the default (initial) ssid and password. They can still be changed in the web UI later.
The connection code is the same; so that shouldn't have any impact whether you compile the credential in the firmware or not.

[fvanroie]

This is certainly not by design. Searching the net yields a lot of similar issues, so there could be an underlying problem that you're experiencing too. Like this forum post, which also included a mitigation.

A common theme seems to be related to Arduino 1.0.x issues. With the 0.6.3-dev release we are set to switch to Arduino 2.0.x which implements many Wifi improvements which could already fix this issue.

Can you please provide the openHASP Version and Module Core Version from the information page?

[Braehead]

I can try this evening (UK time).

[Braehead]

OK. I was at home on a long phone call and installed (0.6.3-dev b471ff0) onto a new board with a full erase, and it attached to the weakest signal matching the SSID and passphrase. I'm presuming it won't roam, but I will try this later and get back to you.

[fvanroie]

0.6.3-dev b471ff0 is a month old. You need the latest code from yesterday to test if the Wifi tweaks make any difference.

[Braehead]

Corrected last night, sorry my mistake. Although one unit had to be fully flashed, as the OTA method failed repeatedly.

The good news is that appears to be working (this fix). But I would like to action some more tests over the next couple of days.

I think there needs to be an algorithm to use the strongest signal via an AP search, not just the first successful connection. At the moment, if there is a match, it just connects, regardless of the signal quality.

Also, and I don't know if this will/is an issue any more. But if the AP is weak (ie getting beacon timeouts due to range), then you can change the WiFi details via the GUI. BUT, when applied via a GUI reset, the credentials are lost if the AP can't be connected to (error was no IP received), which I think is a DHCP negotiation loss shortly after AP connection. Its fine via the console - it keeps trying the new credentials.

I'll test further and come back with results.

[fvanroie]

This change made it into v0.6.3-rc1 which we are testing now. It would be nice if you can this this before we release it.