Mbed-os: 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)

d5de476f74dd4de27012eb74ede078f6330dfc3f

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.

[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 1703ed38c902c73b416ce62ccf5d768e801fe2a2 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 (https://github.com/ARMmbed/mbed-os/pull/3232) related?

[JanneKiiskila]

Well, @SeppoTakalo tested it against mesh networking - which is the role the Oulu team has. We do not have WiFi team here.

Secondly, the change you bisected to this - it has nothing to do with the original issue - that's another change mbedOS team made to the same area (with the same results).

[geky]

3232 is unrelated, the DNS query is completing successfully.

Looking at the stack trace of the first socket failure narrowed down the bug pretty quickly.

The esp8266 handles UDP a bit oddly, it actually treats it like a connection based protocol. Because of this, the esp8266 has never returned a valid address from recvfrom. This will likely get fixed in the firmware update that is in progress, but hasn't been high priority since few applications actually use the address from recvfrom.

Client also does not use the resulting address from receive from, but is calling the pal layer in a way that expects an address, causing the application to error even when the data is received successfully.

The easiest fix is to remove these lines and pass NULL to pal_receiveFrom (pal_receiveFrom's documentation indicates this is valid usage):
https://github.com/ARMmbed/mbed-client-classic/blob/master/source/m2mconnectionhandlerpimpl.cpp#L414-L415

---

The reason 1703ed3 reveals the bug is because before pal was interpreting the null address as valid. Adding a check for null (which the pal probably should do) would have also revealed this issue.

And yes, there are tests for this behaviour of recvfrom on there way in, although there are several related issues regarding how these tests are applied generically to network interfaces:
https://github.com/geky/mbed/blob/94ebf499b8bbfe06d7abdfe0b9988143970915ed/features/FEATURE_LWIP/TESTS/mbedmicro-net/udp_echo/main.cpp#L68-L76

[geky]

Opened quick pr on mbed-client-classic: https://github.com/ARMmbed/mbed-client-classic/pull/49
Opened related issue on esp8266-driver: https://github.com/ARMmbed/esp8266-driver/issues/15

[adbridge]

Closing this as not an mbed-os issue.

[teetak01]

Thanks @geky for the quick fix!

[JanneKiiskila]

Turns out "his will likely get fixed in the firmware update that is in progress, but hasn't been high priority since few applications actually use the address from recvfrom." -> well, one of those apps is the provisioning component in Cloud Client. This would really need fixing, as they verify the senders.

[kjbracey-arm]

An alternative might be to connect your UDP sockets, so you don't need to be checking the source address, but I'm not sure how many of the abstraction layers and network stacks support that. Could be equally glitchy.