Added clearing of ipv6 addresses to lwip bringdown function

[mikaleppanen]

Description

Added removal of ipv6 addresses to bring down function. Corrected address semaphore functionality on repeated bring up/down cycles.

Status

READY

Migrations

NO

Related PRs

None

Todos

• Tests
• Documentation

Deploy notes

None

Steps to test or reproduce

None

[0xc0170]

@geky @kjbracey-arm

[geky]

This looks reasonable to me, although @kjbracey-arm knows more about the lwip-interface's implementation details.

Interesting that there's not a better way to zero the semaphore other than completely reinitializing it.

[sg-]

@mikaleppanen needs a conflict resolved.

@kjbracey-arm Any feedback on this?

[kjbracey]

No problem with the lwIP bit - everything you do to it involves grobbling around in its data structures.

The semaphore looks a bit nasty, but it's artefact of the fact the existing code is trying to use a semaphore where it should be using something like a signal. Not a fan of semaphores in general. Almost always the wrong primitive. (Any plans for condition variables?)

[geky]

Thinking about it more, should this actually treat the semaphore like a condition variable and just expect spurious wakeups (ie from failed inits)?

The has_addr portion of the initialization sequence be similar to this to avoid reinitializing the semaphore:

// If doesn't have address
while (true) {
    if (mbed_lwip_get_ip_addr(true, &lwip_netif)) {
        lwip_connected = true;
        break;
    }

    ret = sys_arch_sem_wait(&lwip_netif_has_addr, 15000);
    if (ret == SYS_ARCH_TIMEOUT) {
        return NSAPI_ERROR_DHCP_FAILURE;
    }
}

[0xc0170]

@mikaleppanen please resolve the conflicts

[mikaleppanen]

@0xc0170 conflicts have been resolved.

[sg-]

/morph test-nightly

[geky]

/morph test-nightly

[mbed-bot]

Result: FAILURE

Your command has finished executing! Here's what you wrote!

/morph test-nightly

Output

mbed Build Number: 1089

Test failed!

[0xc0170]

@bridadan K22F-GCC_ARM.tests-mbed_drivers-lp_timeout.1sec LowPowerTimeout from deepsleep - unrelevant failure, any known issue with this one? Should be green.

[bridadan]

@0xc0170 Yeah I saw that as well. I've never seen that issue before, but that is a legitimate device failure (the device detected that failure and reported it).

The numbers it reported seem funny though. The expected vs the actual value (1000000 vs 199967357 respectively) are wayyyy off. I can see from the test log that the device did sleep for approximately ~1sec, but the timer reported that it slept for ~200 seconds. Is this a case of rollover or overflow? It might just be a very occasional failure.

Feel free to run the tests again or try it locally.

[geky]

It definitely looks unrelevant with respect to this pr right?
/morph test

[mbed-bot]

Result: ABORTED

Your command has finished executing! Here's what you wrote!

/morph test

[0xc0170]

/morph test-nightly

[mbed-bot]

Result: FAILURE

Your command has finished executing! Here's what you wrote!

/morph test-nightly

Output

mbed Build Number: 1122

Test failed!

[bridadan]

Tests look ok, the failure is caused by test machine load when measuring the timing data from the device, doesn't look like any actual failure 👍

[mikaleppanen]

can this be merged?

[bridadan]

If @kjbracey-arm and/or @geky are happy with the changes it should be ok to come in.

[geky]

Definitely useful to have this merged. Thanks for submitting the patch!