08-interop: add test for WiFi <-> DHCPv6 router

[benpicco]

Add a specification for testing the WiFi uplink with an esp*.
This also allows us to test routing to the wider internet (via border router) and DNS operation.

Requirement is a IPv6 uplink and a router that allows enabling prefix delegation (IA_PD) via DHCPv6.

Fixes #150

[miri64]

IMHO this would fit better in with 08-interop.

[miri64]

Also addresses #150 in part.

[gschorcht]

This covers only esp_wifi. With driver atwinc15x0 also arduino-mkr1000 and feather-m0 have a WiFi interface as netdev default.

[miri64]

As I have the feeling this discussion point got lost:

IMHO this would fit better in with 08-interop.

I really don't see why we need a whole new spec just for WiFi. In the end this is about interoperability with other OSs (namely FritzBox OS/OpenWRT when one follows your instructions) and the tools of other OSs

[miri64]

This covers only esp_wifi. With driver atwinc15x0 also arduino-mkr1000 and feather-m0 have a WiFi interface as netdev default.

Remember that those also need to be available to the release testers! (+ AFAIK the feather-m0 is not shipped with a WiFi module per default)

[benpicco]

Ok, I can move it there.
The advantage of using an esp for this test is that we can test border router functionality without any additional hardware.

[gschorcht]

AFAIK the feather-m0 is not shipped with a WiFi module per default

There is the Feather M0 board with and without WiFi. To avoid that separate board definitions are necessary only because of this difference, the respective board is simply defined using the pseudomodule feather-m0-wifi. In case the pseudomodule feather-m0-wifi is used, atwinc15x0 is the default netdev.

[miri64]

There is the Feather M0 board with and without WiFi. To avoid that separate board definitions are necessary only because of this difference, the respective board is simply defined using the pseudomodule feather-m0-wifi. In case the pseudomodule feather-m0-wifi is used, atwinc15x0 is the default netdev.

Off-topic: we should really find a concise way to unify such board variants. Even for the slwstk6000b variants there are now separate directories.

[gschorcht]

There is the Feather M0 board with and without WiFi. To avoid that separate board definitions are necessary only because of this difference, the respective board is simply defined using the pseudomodule feather-m0-wifi. In case the pseudomodule feather-m0-wifi is used, atwinc15x0 is the default netdev.

Off-topic: we should really find a concise way to unify such board variants. Even for the slwstk6000b variants there are now separate directories.

OK, we have the same for esp32_ttgo_t_beam. There are different versions v1.0, v1.1 and v1.2 of the same board but with different hardware and GPIO configurations. The different versions are also defined as pseudomodules. Otherwise the number of board definitions would explode.

[miri64]

OK, we have the same for esp32_ttgo_t_beam. There are different versions v1.0, v1.1 and v1.2 of the same board but with different hardware and GPIO configurations. The different versions are also defined as pseudomodules. Otherwise the number of board definitions would explode.

But defining them as pseudo-modules it (1) breaks the board abstraction and (2) leaves them untested by our CI systems which relies on the boards being listed somewhere.

[benpicco]

I did something different for openlabs-kw41z-mini-256kib and stm32f429i-disco: Include the base board and just change a variable / add a module.

[gschorcht]

But defining them as pseudo-modules it ... leaves them untested by our CI systems which relies on the boards being listed somewhere.

That's clear.

[miri64]

Let's move to a dedicated issue for that RIOT-OS/RIOT#14681

[fjmolinas]

Would it be possible to add a automatic release test for this based on @miri64 framework?

[miri64]

Would it be possible to add a automatic release test for this based on @miri64 framework?

As there is

1. An interaction required with an external router / DHCPv6 server
2. No template for @benpicco to work of of (there are currently no border router tests automated)

I'd say: not yet :-).

[miri64]

ping @benpicco? Needs rebase after #116, I'm afraid.

[benpicco]

Rebased.

[miri64]

Lastly some spelling nits.

[miri64]

ACK. Please squash. Other boards with WiFi support and automated tests can always added be later.

[miri64]

Wait... does this actually work? Should this have been marked as experimental?

[benpicco]

It works for me™.
Some independent testing sure wouldn't hurt though.
I've found that exposing RIOT to the real IPv6 (Inter)net can uncover corner cases that have been overlooked before.

[miri64]

Then I guess you have to shepherd these tasks for at least a few upcoming releases ^^"