LWIP::get_ipv6_addr for link-local only

[tymoteuszblochmobica]

LWIP::get_ipv6_addr is modified to avoid netif NULL return if only link-local adress
exists.
Second netifs loop iteration is added.
On original pass global IP is preffered if it fails also netifs for link-local are considered on second loop.
This can avoid to return NULL if local adress exists.

Initial IPV6 issue #11442

Description

Pull request type

[x] Fix
[ ] Refactor
[ ] Target update
[ ] Functionality change
[ ] Docs update
[ ] Test update
[ ] Breaking change

Reviewers

@SeppoTakalo
@mikaleppanen
@kjbracey-arm
@michalpasztamobica

Release Notes

[ciarmcom]

@tymoteuszblochmobica, thank you for your changes.
@SeppoTakalo @kjbracey-arm @michalpasztamobica @mikaleppanen @ARMmbed/mbed-os-ipcore @ARMmbed/mbed-os-maintainers please review.

[michalpasztamobica]

Considering the fact that LWIP_IPV6_NUM_ADDRESSES is 3, I personally think this solution is acceptable.
Although it would be great to know what is the point of ignorig the linklocal addresses in the first place. @kjbracey-arm , do you know the reason behind this check:
!ip6_addr_islonklocal(netif_ip6_addr(netif, i)) in line 91 of lwip_tools.cpp?
Perhaps there is a good reason not to return it?

[kjbracey]

I think the desired behaviour is what you're doing here.

This call is used in the context "give me one address", and for that we want to give a global address if possible, hence the existing check, but it should fall back to link-local if that's all it's got.

I've cross-checked what Nanostack::get_ip_addr does, and it uses a Nanostack call that returns a single address, preferring addresses with wider scope, which achieves the same effect as this.

However, I think you need to check the event generation for NSAPI_STATUS_GLOBAL_UP. I think if you change this routine, it will trigger HAS_ANY_ADDR and hence that event prematurely.

If you compare with Nanostack, you'll see that it checks that the "get address" function hasn't returned the local address to distinguish LOCAL_UP and GLOBAL_UP.

LWIP currently isn't generating LOCAL_UP at all. I think that dates back to when it was IPv4 only, which doesn't really have the concept. (Unless we used autoip, which we don't).

[tymoteuszblochmobica]

@kjbracey-arm I changed netif status generating.
Please check if this is what you suggested.

[kjbracey]

Looks plausible to me.

[0xc0170]

CI started

[mbed-ci]

Test run: FAILED

Summary: 3 of 4 test jobs failed
Build number : 1
Build artifacts

Failed test jobs:

• jenkins-ci/mbed-os-ci_build-ARM
• jenkins-ci/mbed-os-ci_build-IAR
• jenkins-ci/mbed-os-ci_build-GCC_ARM

[0xc0170]

I don't understand how failures relate to this one , from one log : [Error] main.cpp@34,25: use of undeclared identifier 'MBED_CONF_APP_ECHO_SERVER_HOSTNAME' [Error] main.cpp@37,18: use of undeclared identifier 'MBED_CONF_APP_ECHO_SERVER_PORT'

Is this CI config mismatch? cc @VeliMattiLahtela

[0xc0170]

CI restarted

[mbed-ci]

Test run: FAILED

Summary: 3 of 4 test jobs failed
Build number : 2
Build artifacts

Failed test jobs:

• jenkins-ci/mbed-os-ci_build-ARM
• jenkins-ci/mbed-os-ci_build-IAR
• jenkins-ci/mbed-os-ci_build-GCC_ARM

[0xc0170]

One failure in the logs : [Error] LWIPInterface.cpp@232,17: no member named 'addr' in 'ip_addr' . 2 targets fail across toolchains, please review

[tymoteuszblochmobica]

[Error] LWIPInterface.cpp@232,17: no member named 'addr' in 'ip_addr' is fixed now

[adbridge]

CI started

[mbed-ci]

Test run: SUCCESS

Summary: 11 of 11 test jobs passed
Build number : 3
Build artifacts