Complications during networking tests

[bridadan]

Description

• Type: Enhancement
• Priority: Major

Enhancement

There are a number of issues that can crop up when running networking tests. This issue attempts to keep track of them so we don't forget what things we've tried and what things we still need to do to get them as stable as possible.

mbeds with non-unique MAC addresses will fail to get IP addresses.

We attempted to fix this in #4240 by adding to the existing mbed_mac_address function the ability to return a user-specified mac address. This doesn't work since most vendors that have an LWIP implementation have already overridden this function.

ACTION: Have a discussion on what layer this functionality should exist, as this will not be a unique problem to interfaces making use of LWIP.

Certain network interfaces will not a have direct connection to host PCs that sit behind a firewall

Almost all of our current networking tests assume a direct connection can be established from the device to the host PC. This may not always be the case. This is particularly an issue with Cellular.

ACTION: Figure out how to remove this dependency, or explore the possibility of creating temporary public tunnels.

FYI @geky

[bulislaw]

I've acknowledged the issue here #4079 and wanted to provide an API (not necessarily in this PR but as follow up to this work depending on time) for generic MAC address generation.

[cmonr]

@bridadan Is this issue still relevant, since it's been inactive for over half a year?

[geky]

The solution here is to use echo servers for device testing. @SeppoTakalo already has plans to move the DTLS handshake test that way.

I think you can close this because it's being tracked elsewhere.