Fallback to other connection configuration when box can't connect to network in client mode?

[peteruithoven]

Currently when you're communicating through access point mode to the box, you try to make it connect to an existing network, but mistype the password you will lose the connection (having no feedback) and you can only reconnect trough wire.
Even when you restart this last configuration will be on the top of the list and it will fail to connect again.
Should we automatically remove the configuration it can't connect to, and try to reconnect, so it falls back to something else? When it was previously an access point mode it will become an access point again. When it was previously connected to an WiFi network and this network is available it will connect to that, if none known are available it will become an access point as well.

We would need to change around the api to provide feedback (like "couldn't connect to network") because this feedback would be overriden by the reconnection attempt.

[olijf]

I did some research into this issue. If you setup your WiFi-Box using a cable everything is as expected. You get some feedback stating that your password was incorrect but the WiFi-Box stays in STA mode. Shouldn't it switch back to AP mode when it is unable to connect?
A wifi check is only done at boot (so if you take your WiFi-Box on the road there is no issue)

Can we create a little deamon that checks if wifi is still connected and if not resets your wifi connection to AP mode?

I made a little diagram of the issue:

[peteruithoven]

Let's keep this issue focused on one issue, the fact that a wifibox that gets a wrong password can only be connected to by cable.
Let's open a separate issue on how we handle wifi network disconnections, if there isn't one already.

Shouldn't it switch back to AP mode when it is unable to connect?

Do you have an advice on this matter? How would you handle this? Would you handle it like we describe in the Always available diagram:
https://docs.google.com/drawings/d/1X6cbUa3I4X_EGkZDbpwOyFRse88KpEWRIQxKotPnKFc/edit

[olijf]

I did a little experiment with a possible fallback solution:
In https://github.com/Doodle3D/doodle3d-firmware/blob/master/src/rest/api/api_network.lua#L154 I added the functionality of the openap function, so when a connection is unsuccessful the WiFi-Box automatically switches back to AP mode. The problem now is that it switches back rather fast to AP mode so no message is displayed to the user.
changing the correct lines in https://github.com/Doodle3D/doodle3d-firmware/blob/master/src/network/netconfig.lua seems nicer.

at the moment I see 3 possible solutions:

• Use this fix when a user enters the wrong key.
• Look into a better fallback solution solving other issues like lost connections etc. removing the need to restart your WiFi-Box when the shit hits the fan.
• Rewrite the complete network stack of the API using something like ubus over uhttp like LuCi2 does. (I would like to look into this... it would simplify our API enormously and allow us to focus on more important things) https://wiki.openwrt.org/doc/techref/ubus#access_to_ubus_over_http

I'll look into other possibilities on monday.

[olijf]

I added this fix in in Doodle3D/doodle3d-firmware@9d07647 only 1 minor issue: if you havent actually clicked the 'open accesspoint' before the network comes back as 'undefined'

[olijf]

seems that the only calling the setup AP function is not enough, has this something to do with how uci works etc?

I created a working fix that follows this principle : +1:

See Doodle3D/doodle3d-firmware@c6b01a3
and had to do some strange workaround to get things going:
Doodle3D/doodle3d-firmware@0d9684b
I suspect its the way UCI works.

[olijf]

Maybe this one can be closed? As it is available in the current beta release?

[peteruithoven]

Yes, that makes sense. The relevant pull request: Doodle3D/doodle3d-firmware#63