We’re running a couple of test sites with multiple imps installed. The sites have more than one access point with the same SSID. If everything is running well, there is usually no concern about which BSSID the imp is connected to. However, one of the APs failed recently. The access point was still supporting wireless connections but had no backhaul. There were other access points in the vicinity, with the same SSID, good signal strength and viable paths to the imp servers. The wifi side of the imp never saw fit to try the other BSSIDs, despite repeatedly failing to connect to the one closest to it.
If this is expected behaviour, wouldn’t it be wiser to try other BSSIDs if the closest one accepts connections but will never permit access to the imp server?
This could also be perceived as a vulnerability, as the strong signal from an incorrectly-configured or deliberately-spoofed AP could block imps in the field.
A weighting algorithm could be employed to choose a particular BSSID based on RSSI and previous success. A simpler, but still effective, solution would be to randomly select BSSIDs when multiple ones are detected.
The other option would be to expose BSSID selection through the imp API. Although, that could had ramifications for lots of aspects of the functionality. If it were implemented, it’d be possible to whitelist or blacklist MACs or to preferentially select one.
Roaming between different APs in the same SSID is handled within the imp’s wifi chip itself; we don’t really get to vote. An SSID some of whose APs have backhaul and some don’t, is a bit of a corner case really. Much more common (er, especially if you’re on the same ISP I am) is that all the APs lose backhaul simultaneously because somewhere upstream of your site has gone down. And in that case, roaming to a non-optimal (lower signal strength) AP would only make matters worse.
Thanks for response , but that’s disappointing to know.
In our experience so far, there is no way to predict exactly how client networks will be configured. Private houses and business will set up secondary routers with the same SSID/pw as primary routers that they share a LAN connection with, rather than using any repeater/mesh arrangement. The LAN link between them can be cut, yet the secondary router will still happily accept wireless connections.
I think that roaming across APs can work as we are doing this already, although they must have distinct SSIDs for us to do so.
Related to this, I’m doing a thorough test on the adjusted wifi functionality of release 30. Could I please get some clarity on what circumstances we would expect NOT_CONNECTED to be returned by the server.connect() callback?
Constant Value Description
NO_WIFI 1 Failed to join WiFi
NO_IP_ADDRESS 2 Failed to get an IP address
NO_SERVER 3 Failed to connect to the Electric Imp server
NOT_RESOLVED 4 The IP address of an Electric Imp server could not be resolved
NOT_CONNECTED 0 The imp is not able to connect for some other reason
I seem to be getting NOT_CONNECTED all the time when the AP is simply not there. Shouldn’t I be getting NO_WIFI? Or it that reserved for password incorrect or when the AP refuses the connection?
The decision when and why to roam to another AP is done inside the wifi client chipset and varies from one vendor to another. The standards don’t specify when to roam and it’s proprietary to the vendor. There are vendor specific extensions to AP’s to encourage a client should roam (for example a heavily loaded AP) but at the end of the day it’s the chipset that decides.
For a wifi denial of service there’s no need to use a bogus AP, just use a spark gap generator. I’m sure photonicinduction on youtube could whip up a nice wifi jammer.
The exact value appearing in the connect callback (or in the unexpected-disconnect handler) can vary depending on quite subtle timing issues. It’s probably best to view them as SERVER_CONNECTED (5) and OTHER (other).