If number of scanned networks is zero, while getting the list, since we try
to allocate zero bytes, we get a NULL pointer in response. This is considered
as an error and the provisioning worflow breaks there.
Adding a check before allocation resolves the issue.
With the introduction of cookies to track a session, it is possible that the
clients restart the provisioning on the same session, specifically when a user
cancels a current provisioning attempt. This can result in an error as the state
on the device side and client side will go out of sync.
This has now been changed such that if SESSION_STATE_CMD0 is received on
an existing session, the state is reset and flow allowed to continue.
Earlier, a "socket connection" was being considered as a protocomm "session".
However, for HTTP, we cannot expect clients to necessarily use the same
socket for all requests of a given transaction. This was indeed causing
some failures for Wi-Fi provisioning from Android phones.
So, we have introduced http cookies to track a session even if the socket
connection does not stay intact throughout the transaction.
This change is backward compatible. If the client does not use cookies, the
socket connection will be considered as the session.
Closes: https://github.com/espressif/esp-idf/issues/6316
Reference: https://github.com/espressif/esp-idf/pull/6330
This commit fixes a bug as well as changes a behaviour.
Bugfix: During softap/httpd based provisioning, if a session was closed
midway and a new one started, it would never proceed if the http server
assigns same socket number to the new session (which happens almost always).
Now, if a session is closed, using the http callbacks, the older session
data is cleared so that a new one can be created.
Behavioural change: If a client (mobile app particularly) does not use
persistent http session i.e. all provisioning communication on the same
socket, the provisioning may fail. Earlier, since the session context was
not getting cleared, even if the client closed a session and continued
on a new one, it would go through if the socket number assigned was same
(which happens almost always).
Ideally, from a security perspective, all communication related
to secure provisioning must happen on the same socket, and so, this
change is required.
It was observed that after sending credentials, if the first
Wi-Fi conection attempt fails, the Wi-Fi provisioning managager
ignores subsequent Wi-Fi events. So, even if the device eventually
connects to the AP, the provisioning stays on indefinitely.
Changing a check so that subsequent events are also captured and
provisioning finishes successfully.
Piyush Shah