Because during the provisioning process the device switches between different roles, connects to different APs, and changes its IP addresses, host commands may not be properly served. As a result, when the host issues a command during an active provisioning process, the SL_RET_CODE_PROVISIONING_IN_PROGRESS (–2014) error is returned. Only the sl_WlanProvisioning and sl_stop commands are allowed. If the host is interested in executing a different command, it must either wait for the provisioning process to end, or manually stop it (using the SL_WLAN_PROVISIONING_CMD_STOP command). In addition, events that may be sent to the host during the provisioning connection attempts (such as NETAPP_IPACQUIRED) are blocked and will not reach the user (except for the provisioning dedicated events, such as the provisioning status event).

In some cases, after provisioning starts the APIs are unblocked to let the host perform some actions that are necessary for completing the provisioning process. These actions follow:

• External Confirmation: when the confirmation result is sent to the user over the Internet, the host must open a socket to the cloud server. To enable it, the APIs are unblocked immediately after the PROVISIONING_CONFIRMATION_IP_ACQUIRED status event is sent to the host.
• External Configuration: when APSC plus External Configuration mode is used, the host must open sockets during the configuration stage. To enable it, the APIs are unblocked immediately after the PROVISIONING_EXTERNAL_CONFIGURATION_READY status event is sent to the host.
• Auto-Provisioning: when provisioning is auto-started, the APIs are still allowed (unlike host-initiated provisioning where the APIs are blocked immediately after the provisioning process has started). APIs are blocked only after user activity is detected (for example, a profile is added).