mbed-os-example-wifi hangs on ODIN-W2

[juhaylinen]

Description

• Type: Bug
• Priority: Critical

---

Bug

Target
UBLOX_EVK_ODIN_W2

Toolchain:
GCC_ARM|ARM|IAR

mbed-cli version:
1.2.2

mbed-os sha:
b8d2180

Expected behavior
mbed-os-example-wifi is run successfully

Actual behavior
mbed-os-example-wifi hangs and doesn't scan the network or connect to AP

Steps to reproduce
Compile mbed-os-example-wifi and try to run on u-blox Odin board

Bug analysis
It seems that PR #5630 breaks the WiFi connectivity

[juhaylinen]

Priority is now Critical

[0xc0170]

It seems that PR #5630 breaks the WiFi connectivity

Can you confirm that without this pull request, the example works?

@ARMmbed/team-ublox Please review

[juhaylinen]

Yes, If I revert the pull request, the example works.

[0xc0170]

cc @adustm Please review, relates to #5630

[adustm]

Hello,
Can you clarify at which moment the mbed-os-example-wifi is using SHA1 / SHA256 or MD5 ?
I can't remember it.
Kind regards
Armelle

[juhaylinen]

Narrowed the issue down to MD5 calculation. My guess is that the binary driver (libublox-odin-w2-driver) uses MD5.

It is also used in this file https://github.com/ARMmbed/mbed-os/blob/master/features/FEATURE_LWIP/lwip-interface/lwip-sys/lwip_tcp_isn.c but the mbed-os-example-wifi hangs before the code is executed.

[andreaslarssonublox]

Hi,
This will probably not work without a new driver since MD5 is used in the driver. I've compiled a new driver for test but it fails when the TCP communication starts.

I think I've located where it goes wrong. In the function lwip_hook_tcp_isn the MD5 context is created on the stack but there is no initialization of the struct and therefore bogus values(especially length field is wrong 0xd8) are used in lwip_md5_update resulting in stack overwrite.

@adustm Shouldn't lwip_md5_starts clear the whole struct or how is this supposed to work?

[adustm]

Hello @andreaslarssonublox
Thanks for narrowing the issue. I was not aware the lwip files were using the md5 functions.

The md5_context is initialialized in the md5_init function.
I think you should use
lwip_md5_init before lwip_md5_start
and lwip_md5_free after lwip_md5_finish

@andresag01 or @hanno-arm , could you confirm that ? Shall md5_start initialize md5_context memory or shall md5_init be called here

mbed-os/features/FEATURE_LWIP/lwip-interface/lwip-sys/lwip_tcp_isn.c

Line 181 in 0978062

lwip_md5_starts(&ctx);

?

Kind regards

[hanno-becker]

Hi,

@adustm is right: The usage of any context structure in Mbed TLS must be delimited by calls to the respective xxx_init and xxx_free functions. Specifically, the MD5 context in question must be initialized via lwip_md5_init and freed via lwip_md5_free before/after use with the actual digest calculating functions lwip_md5_{starts/update/finish}.

Kind regards,
Hanno

[juhaylinen]

Fixed in #6032