drivers: wifi: simplelink: add timeout for fast connect feature

[GAnthony]

The SimpleLink wifi driver enables the Fast Connect method of
WiFi provisioning, which allows the network coprocessor to
reconnect to a previously connected Access Point (AP) on
startup.

Previously, if Fast Connect failed to connect, any network
socket applications would inevitably fail, as there would have
been no wifi connection.

This patch adds a configurable timeout for the Fast Connect
feature, after which timeout, an error is logged informing
the user to manually reconnect to an AP.

Reconnection is typically accomplished by separately running the
wifi sample shell program.

Fixes: #11889

Signed-off-by: Gil Pitney [email protected]

[GAnthony]

@vanti, when you get a chance, can you please validate to see if this helps alleviate the issue #11889 for networking socket samples?

This fix is confined to the SimpleLink driver, and it's related to the "fast connect" feature, so does not involve any change to the networking auto init.

[codecov-io]

Codecov Report

Merging #12505 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master   #12505   +/-   ##
=======================================
  Coverage   53.78%   53.78%           
=======================================
  Files         242      242           
  Lines       27697    27697           
  Branches     6729     6729           
=======================================
  Hits        14896    14896           
  Misses       9997     9997           
  Partials     2804     2804

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 74dbe33...987708c. Read the comment docs.

[jukkar]

LGTM

[jukkar]

recheck

[vanti]

@vanti, when you get a chance, can you please validate to see if this helps alleviate the issue #11889 for networking socket samples?

@GAnthony I tried the http_get sample, and I am still seeing the error for some reason:

[00:00:00.000,464] <dbg> wifi_simplelink.simplelink_init: SimpleLink driver Initialized
[00:00:00.415,739] <err> wifi_simplelink: [WLAN ERROR] Device disconnected from the AP: ThingsNet
[00:00:00.415,747] <err> wifi_simplelink: BSSID: 2c:30:33:51:53:33 on error: 1
[00:00:00.575,563] <err> wifi_simplelink: [WLAN ERROR] Device disconnected from the AP: ThingsNet
[00:00:00.575,571] <err> wifi_simplelink: BSSID: 2c:30:33:51:53:33 on error: 1
***** Booting Zephyr OS zephyr-v1.13.0-3238-g11075de733 *****
Preparing HTTP GET request for http://google.com:443/
getaddrinfo status: -2
Unable to resolve address, quitting
[00:00:01.344,011] <inf> wifi_simplelink: [WLAN EVENT] STA Connected to the AP: ThingsNet, BSSID: 2c:30:33:51:53:33
[00:00:01.349,075] <dbg> wifi_simplelink.simplelink_iface_init: MAC Address 08:00:28:5b:58:9b
[00:00:01.360,091] <err> wifi_simplelink: Could not resolve name: google.com, retval: -6152
[00:00:02.063,340] <inf> wifi_simplelink: [NETAPP EVENT] IP set to: IPv4=192.168.1.127, Gateway=192.168.1.1

I added
CONFIG_WIFI_SIMPLELINK_FAST_CONNECT_TIMEOUT=30

to samples/net/sockets/http_get/boards/cc3220sf_launchxl.conf. Is there anything else I need to do?

[GAnthony]

@vanti, no need to update the .conf file, the default is 30 seconds.
Can you ensure the test is based on this PR commit? It shouldn't get to main() until the wifi connect occurs, or times out with an error message.

[vanti]

@GAnthony I am on commit

commit 11075de733579fbf2f1d02aa46690d3ae4bcabc6 (HEAD -> PR_12505, gil/fix_fast_connect_race, validate_12505)
Author: Gil Pitney <[email protected]>
Date:   Tue Jan 15 18:44:29 2019 -0800

    drivers: wifi: simplelink: add timeout for fast connect feature

I can see
CONFIG_WIFI_SIMPLELINK_FAST_CONNECT_TIMEOUT=30
in .config

The problem always happens on the first run after power cycling. I can see it enter main() before getting an IP address. I had also previously flashed the blinky example.

-Vincent

[pfalcon]

So, how does this patch work? Does it stop Zephyr boot process until the device is connected to AP, for up to 30s? If so, I'd say that delay is too big, and should be 5-10s by default.

[GAnthony]

The problem always happens on the first run after power cycling. I can see it enter main() before getting an IP address. I had also previously flashed the blinky example.

OK, after more testing, I now see an error sometimes:
[00:00:00.990,584] wifi_simplelink: [WLAN EVENT] STA Connected to the AP: GP-Galaxy, BSSID: 1c:99:4c:40:ea:ae
[00:00:00.994,984] wifi_simplelink.simplelink_iface_init: MAC Address 04:a3:16:45:b0:90
[00:00:01.005,665] wifi_simplelink: Could not resolve name: google.com, retval: -6152

The -6152 error code is
#define SL_ERROR_NET_APP_DNS_NO_SERVER (-6152L) /* No DNS server was specified */

But, this comes after connection succeeds, so there must be some precondition not always being met before calling SimpleLink's sl_NetAppDnsGetHostByName() function.

Note: with the new Logging subsystem delayed printing, printk's from main might be out of order with respect to Log prints, so debugging driver startup with logs/printk's is now more challenging.

I'll need to see what could be the intermittent causes of this SimpleLink error code.

[GAnthony]

So, how does this patch work? Does it stop Zephyr boot process until the device is connected to AP, for up to 30s? If so, I'd say that delay is too big, and should be 5-10s by default.

Yes. A 5-10s default would be reasonable. Typically, the WiFi connection either succeeds within a few seconds, or not at all.

[GAnthony]

Changes in this update:

• Lowered default wait to 7s from 30s based on @pfalcon's request;
• Moved timeout to the IPV4 Acquired event from the Connected event.

@vanti,
It seems the failure in the previous version was caused by the NWP not having enough time to cache the DNS server addresses; it was necessary to wait for the NWP's DHCP client to finish. Hence, waiting on the IPV4 address to be acquired first fixed the getaddrinfo failures.

After connecting to the AP with the WiFi shell sample,
the http_get test (with TLS) passed 10 times each running from both SRAM, and Flash, with no failures.

[GAnthony]

recheck

[pfalcon]

Thanks.