TLS handshake fails using WiFi in mbed OS 5.2.3

[JanneKiiskila]

Description

• Type: Bug
• Related issue: #abc
• Priority: Blocker

---

Bug

Target
K64F with WiFi shield (UART)

Toolchain:
GCC_ARM

Toolchain version:

mbed-cli version:
(mbed --version)
0.9.10

meed-os sha:
(git log -n1 --oneline)

d5de476

DAPLink version:

Expected behavior

mbed-os-example-client connects over WiFi

Actual behavior

mbed-os-example-client does not connect over WiFi with 5.2.3.
However, it does work perfectly (same exact client) with 5.2.0.

Steps to reproduce

Configure your WiFi to mbed_app.json.
build the app (mbed compile -m K64F -t GCC_ARM -c)
watch the logs

*** Release blocking error, IMHO. ***

[JanneKiiskila]

mbed-os-exmaple-client-logs-wifi-bug.zip

[JanneKiiskila]

It connects;

Connected to Network successfully
IP address 192.168.137.224

However, the TLS handshaking fails.

[DBG ][mClt]: M2MConnectionSecurityPimpl::start_connecting_non_blocking - handshake ret: 1, ssl state: 2

[DBG ][mClt]: receive_handler()

[DBG ][mClt]: receive_handshake_handler()

[DBG ][mClt]: M2MConnectionSecurityPimpl::continue_connecting

[DBG ][mClt]: mbedtls_timing_get_delay

[DBG ][mClt]: mbedtls_timing_get_delay - ret 0

[DBG ][mClt]: receive_from_socket

[DBG ][mClt]: M2MConnectionSecurityPimpl::continue_connecting, ret: -1000

[DBG ][mClt]: ret -1000

[DBG ][mClt]: We wait for next readable event

[DBG ][mClt]: receive_handler()

[DBG ][mClt]: receive_handshake_handler()

[DBG ][mClt]: M2MConnectionSecurityPimpl::continue_connecting

[DBG ][mClt]: mbedtls_timing_get_delay

[DBG ][mClt]: mbedtls_timing_get_delay - ret 0

[DBG ][mClt]: receive_from_socket

[DBG ][mClt]: M2MConnectionSecurityPimpl::continue_connecting, ret: -1000

[DBG ][mClt]: ret -1000

[DBG ][mClt]: We wait for next readable event

[DBG ][mClt]: M2MConnectionSecurityPimpl::timer_expired

[DBG ][mClt]: M2MConnectionSecurityPimpl::continue_connecting

[DBG ][mClt]: mbedtls_timing_get_delay

[DBG ][mClt]: mbedtls_timing_get_delay - ret 1

[DBG ][mClt]: receive_from_socket

[INFO][mClt]: PAL Socket returned: -65522

[DBG ][mClt]: M2MConnectionSecurityPimpl::continue_connecting, ret: -1

[ERR ][mClt]: M2MConnectionSecurityPimpl::timer_expired - handshake timeout

[DBG ][mClt]: handle_connection_error

[DBG ][mClt]: M2MInterfaceImpl::socket_error: (6), retry (1), reconnecting (0)

[bulislaw]

Wifi example gives errors on K64F as well:

pinmap not found for peripheral

[bulislaw]

Ah ignore me, I had some modification for another board. It works fine:

Scan:
Network: AccessNG secured: None BSSID: 18:64:72:42:92:0 RSSI: -83 Ch: 1
Network: Guest-AccessNG secured: None BSSID: 18:64:72:42:92:1 RSSI: -82 Ch: 1
Network: AccessNG secured: None BSSID: 9C:1C:12:3:66:20 RSSI: -86 Ch: 1
Network: AccessNG secured: None BSSID: 9C:1C:12:3:b0:80 RSSI: -66 Ch: 1
Network: Guest-AccessNG secured: None BSSID: 9C:1C:12:3:b0:81 RSSI: -66 Ch: 1
Network: iot_test secured: WPA/WPA2 BSSID: 1C:B7:2C:7c:3d:c0 RSSI: -52 Ch: 3
Network: mbed secured: WPA2 BSSID: 50:6A:3:a5:8c:e3 RSSI: -64 Ch: 4
Network: AccessNG secured: None BSSID: 9C:1C:12:3:a9:80 RSSI: -62 Ch: 6
Network: Guest-AccessNG secured: None BSSID: 9C:1C:12:3:a9:81 RSSI: -62 Ch: 6
Network: AccessNG secured: None BSSID: 18:64:72:42:91:e0 RSSI: -82 Ch: 1
Network: Guest-AccessNG secured: None BSSID: 18:64:72:42:91:e1 RSSI: -80 Ch: 1
Network: AccessNG secured: None BSSID: 9C:1C:12:3:6f:80 RSSI: -43 Ch: 1
Network: Guest-AccessNG secured: None BSSID: 9C:1C:12:3:6f:81 RSSI: -42 Ch: 1
Network: AccessNG secured: None BSSID: 9C:1C:12:3:5a:80 RSSI: -78 Ch: 1
Network: Guest-AccessNG secured: None BSSID: 9C:1C:12:3:5a:81 RSSI: -77 Ch: 1
15 networks available.

Connecting...
Success

MAC: 5c:cf:7f:1c:cc:99
IP: 192.168.1.81
Netmask: 255.255.255.0
Gateway: 192.168.1.1
RSSI: -56

Sending HTTP request to www.arm.com...
sent 38 [GET / HTTP/1.1]
recv 64 [HTTP/1.1 200 OK]

Done

[JanneKiiskila]

@bulislaw - the UART WiFi compiled just fine on K64F, I had no issues with pinmap.

[bulislaw]

Yeah, my bad I was working with another board and forget to change the pins back to default. I assumed that wifi is broken, as title of this issue suggests, it seems that TLS is not connecting properly. I'll update the name so it better reflects nature of the issue.

[bulislaw]

My bisect points to 1703ed3 nsapi - Standardized support of NSAPI_UNSPEC

@geky could you have a look please.

[adbridge]

The associated PR nsapi - Standardize support of NSAPI_UNSPEC #2897

It looks like this change was reviewed and tested to some extent by the folks in Oulu, prior to merge. So it looks like this particular case was not considered in the testing.

[adbridge]

@geky Is this fix that went in for 5.2.3 (#3232) related?