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:
b8d218038

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 https://github.com/ARMmbed/mbed-os/pull/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 https://github.com/ARMmbed/mbed-os/blob/0978062dae544b598bd0d368eae0b39162750b13/features/FEATURE_LWIP/lwip-interface/lwip-sys/lwip_tcp_isn.c#L181
?

Kind regards

[hanno-arm]

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 https://github.com/ARMmbed/mbed-os/pull/6032

[teetak01]

@0xc0170 please open this ticket as it still impacts current release versions.

[0xc0170]

@0xc0170 please open this ticket as it still impacts current release versions.

Can you provide an update what versions are impacted, how, etc? As my understanding, 5.8 does not have this issue anymore.

[teetak01]

5.7.5->5.7.7