test-ci: net.socket.tls: zephyr-v2.6.0-286-g46029914a7ac: frdm_k64f: test fail

[hakehuang]

Describe the bug
test-ci: net.socket.tls: zephyr-v2.6.0-286-g46029914a7ac: frdm_k64f: test fail

To Reproduce
Steps to reproduce the behavior:
cd tests\net\socket\tls_ext

1. mkdir build; cd build
2. cmake -DBOARD=frdm_k64f ..
3. make
4. See error

Expected behavior
test PASS

Impact
tls extend functions

Logs and console output

  *** Booting Zephyr OS build zephyr-v2.6.0-286-g46029914a7ac  ***

    I: Initializing network

    I: IPv4 address: 192.0.2.1

    Running test suite tls_socket_api_extension

    ===================================================================

    START - test_tls_peer_verify_none

     PASS - test_tls_peer_verify_none in 1.389 seconds

    ===================================================================

    START - test_tls_peer_verify_optional

    W: Cannot do DAD IPv6 config is not valid.

    I: ETH_0 enabled 100M full-duplex mode.

Environment (please complete the following information):

• OS: (e.g. Linux, MacOS, Windows)
• Toolchain (e.g Zephyr SDK, ...)
• Commit SHA or Version used: zephyr-v2.6.0-286-g46029914a7ac

[dleach02]

@jukkar, is this test case also expected to only run on a simulated environment? When we run this on hardware it seems to just hang for me in test_tls_peer_verify_optional

[jukkar]

As a general note, all the tests under tests/net are meant to be running on a simulated environment. This means that even if running on a board that provides Ethernet for example, that onboard Ethernet is not used by the tests, because the tests do not test the Ethernet driver but the IP stack features, and we want to control both the rx and tx of the test data.

Not sure about the hang here, perhaps @rlubos has some hints.

[rlubos]

I think it must be something specific to that board, perhaps some configuration defaults. I'm not sure how verbose the output is (i.e. whether it'd inform about stack overflow), but for nRF devices, it was often the case that the default stack was too small when running on hardware. This particular test has no issues running on nRF52840 though (Cortex M4).

[dleach02]

okay... I'll debug this more to figure out what is the issue with our target.

[dleach02]

As @jukkar comments, these tests are designed for simulated environments. In this test case, we end up with two L1 devices; the K64f one and a dummy device. The issue is that I "think" that the bindings are being established on the real ethernet interface instead of the dummy device. I can't figure out how to force the socket to use the dummy interface... tried to use SO_BINDTODEVICE but not sure what name to provide for it to find...

[dleach02]

@rlubos, this test case works on the nRF52840 board because there is only one network interface that gets defined when you build this; the __net_if_loopback interface. On our device, there is the loopback and the actual real ethernet on our boards. This allows the routing to go wonky