WiFi Provisioning Edge Cases: 7 Scenarios That Break IoT Devices in the Field

Your IoT device connects to WiFi in the lab on the first try, every time. You declare WiFi testing done. Three months after shipping, your customer support queue fills up with connection failures. The devices work perfectly - in your lab, on your router, with your credentials.

The edge cases are in the provisioning scenarios your bench test never exercises. Here are the seven that cause the most field failures.

Edge Case 1: WPA3-to-WPA2 Fallback

Your router supports both WPA3 and WPA2. Your device authenticates with WPA3 in the lab. Your customer's older router supports only WPA2 - or a different WPA3 SAE implementation. Your device connects with WPA3 and refuses to negotiate down to WPA2, or silently stalls during the SAE handshake.

Test: Force the lab router to WPA2-only mode, disable WPA3, and run the provisioning sequence. Assert the device connects within 10 seconds. Then configure the router as WPA3-only and provision. Then configure WPA2/WPA3 mixed mode. Three configurations, three test cases, 30 minutes of setup. This test is almost never run manually because it requires reconfiguring the router.

Edge Case 2: Hidden SSID

Corporate and industrial networks often suppress SSID broadcast. Your device's WiFi provisioning flow scans for networks and displays a list - but hidden SSIDs never appear in scan results. Customers need to manually type the SSID. If your UI or provisioning API does not support manual SSID entry, or if the WiFi driver does not send directed probe requests for hidden networks, the device cannot connect.

Test: Configure the lab AP with SSID broadcast disabled. Initiate provisioning with the hidden SSID entered manually. Assert the directed probe request is sent and the association completes.

Edge Case 3: DHCP Lease Expiry During Active Connection

DHCP leases expire. On a short-lease network (some enterprise DHCPs issue 1-hour leases), a device that has been connected for 45 minutes must renew its lease before it expires. If the DHCP renewal fails silently - because the renewal request is lost and the device does not retry - the device's IP address expires, the connection drops, and the device cannot reconnect without a full restart because it thinks it still has a valid IP.

Test: Use TestBot's Ethernet Interface Agent to start a DHCP server with a 60-second lease time. Let the device connect and acquire an IP. At 50 seconds, monitor for DHCP Request (renewal attempt). Assert the renewal succeeds. Then block the renewal by stopping the DHCP server at 50 seconds, assert the device retries, and verify reconnection behaviour when the DHCP server restarts.

Edge Case 4: SSID Change After Provisioning

The customer renames their router SSID - new ISP, new router, network redesign. The device has the old SSID stored and cannot connect. The provisioning flow must be re-entered. Two failure modes here: (1) the device retries the old SSID indefinitely without entering a re-provisioning state, blocking all connectivity; (2) the device enters re-provisioning mode but the stored credentials are not cleared, causing authentication failures with the new network.

Test: Provision the device with SSID_A. Change the AP to SSID_B. Assert the device detects connection failure within 60 seconds. Assert it enters re-provisioning state (or an alert state) rather than retrying indefinitely. Assert re-provisioning with SSID_B credentials succeeds and clears the old credentials.

Edge Case 5: Wrong Password - Retry Loop

Authentication with an incorrect PSK should fail within 5 seconds and stop retrying. Some devices enter a tight retry loop - continuously attempting association and failing - consuming CPU cycles, draining the battery, and flooding the AP with failed authentication attempts. Some routers temporarily block devices that generate too many failed authentication events.

Test: Provision with an incorrect PSK. Assert the device attempts association a bounded number of times (typically 3) and then stops or enters a cooldown state. Assert it does not retry more frequently than once per 5 seconds. Assert it accepts a correct PSK after the cooldown.

Edge Case 6: AP Restart During Active Connection

Power outage. Router reboots. The device loses its connection. The question is how long it takes to reconnect and whether it reconnects without any user intervention. Failure modes: device reconnects but the cloud session is not re-established (MQTT client does not reconnect); device reconnects but with a new IP address that the cloud has not been notified of; device does not reconnect until rebooted.

Test: Use the lab AP's management interface (or a smart plug controlling the AP) to power-cycle the router. Measure time from AP restart to device successfully communicating with the test Webserver Agent. Assert reconnection within 60 seconds. Assert the cloud session (simulated by Webserver Agent) is re-established automatically.

Edge Case 7: Concurrent WiFi Provisioning and MQTT Connection

Many IoT devices try to open a cloud MQTT connection immediately after WiFi association - before the DHCP lease is confirmed and DNS is available. The MQTT connection attempt fails (DNS lookup fails, TCP connect times out), the device's MQTT client enters a backoff state, and by the time DHCP completes and DNS resolves, the MQTT backoff timer has extended to 5 minutes. The device is connected to WiFi and appears online but is not communicating with the cloud for 5 minutes after provisioning.

Test: Measure the time from WiFi association to first successful MQTT connection (using the Webserver Agent as the MQTT broker endpoint). Assert this is under 15 seconds. If it exceeds 30 seconds, investigate the MQTT client's initial connection timing relative to DHCP completion.

Why None of These Appear in Bench Tests

Every one of these scenarios requires a specific network condition that does not exist in the standard lab setup: a WPA3-only AP, a hidden SSID, a short-lease DHCP server, an AP that restarts on command. Setting these up manually for each test run is too slow. Automating them with TestBot's WiFi Agent, Ethernet Interface Agent, and Webserver Agent means running all seven scenarios in a single 20-minute nightly sequence - on every firmware build, before any changes reach production.