examples/gnrc_border_router: add example for WiFi ⇆ esp_now border router #13545
Conversation
benpicco
added
Type: enhancement
benpicco
changed the title
|
@benpicco I'm pretty busy today, I will take a look on it tomorrow. First, I have to understand exactly what the intention of the example is and need some time to remember again on the disussions with @miri64 about ESP-NOW and the 6Lo node handling. So far my understanding of a border router (@miri64 please correct me) was that the inner network behind the border router is not part of the prefix of the outer network. Rather, the border router provides the inner network with its own prefix according to the address configuration at its inner netif (ESP-NOW in our case). In our examples we therefore use 2001:db8::/64 for the inner network. In a network with 6Lo nodes according to RFC 6775, the multihop prefix is disseminated using the Neighbour Discovery. In networks where only 6Lo protocol is used such as ESP-NOW, RPL/DODAG is used for prefix dissemination. If you are using DHCPv6, the nodes are given the outer network prefix and are therefore part of the outer network. In this case, you probably are not using RPL. If so, the nodes that are out of range of the border router will not get a prefix. |
|
In general, not quite sure what you mean with outer or inner network here.
Mainly, the border router is conceptionally just a router between one link-layer technology and another. With RFC 6775 it has a special position in the network (it is basically administering the network). As it is a router to a new subnet it has to has a (subnet-)prefix to route traffic to. That prefix is the prefix we configure either with DHCPv6 or UHCP (which is on top of the border router functionality, but not part of it).
DHCPv6 provides the subnet-prefix for the new subnet constructed by the LoWPAN (i.e. the prefix that RPL uses). It uses prefix delegation for that (which is a distinct operation than from the well-known operation of DHCP(v6) of address assignment). |
|
DHCPv6 is not part of this PRs discussion, but just to clarify in graphic. From the perspective of DHCPv6 client the border router is a box with two interfaces: For the LoWPAN interface (identified by a client-unique identifier i) it requests a prefix delegation from a DHCPv6 servre beyond the upstream interface. The server replies with a tuple (i, prefix) That allows the client to assign an address for that prefix to the LoWPAN interface and the border router (and the downstream routers) to dessiminate this prefix via its router advertisements through-out the LoWPAN. |
|
@miri64 Thanks for the detailed explaination.
Just to be sure, although we use DHCPv6, RPL is used for the inner network, and even nodes that are out of range of the border router get the prefix ? |
RPL and (or only if RPL is not used) the multihop prefix dissemination of RFC 6775, yes. At least with our current feature-set DHCPv6 is only used to provide the border router (= RPL root) with a prefix it can use to bootstrap the rest of the network. Iff we ever implement clients that support address assignment via DHCPv6 (this is totally possible under the given specification, even recommended when IEEE 802.15.4 short addresses are used), we also would need DHCPv6 relay agent (or server) support for the border router and routers. |
It's already for a long time on my ToDo list to activate this flag automatically for |
|
Command to compile the border router has to be - make -C examples/gnrc_border_router BOARD=esp32-wroom-32 USE_ETHOS=0 USE_ESP=1
+ make -C examples/gnrc_border_router BOARD=esp32-wroom-32 USE_ETHOS=0 USE_WIFI=1Changed 😉 |
@miri64 OK, so one last question remains: Do we need the module |
|
@miri64 |
|
@benpicco I can't test it with DHCPv6 yet, my Telekom Speedport Pro does not provide any configuration options for IPv6 for the LAN. |
|
As I remember, before PR #10499 it worked out of the box for ESP-NOW nodes. There was no distinction between nodes that are "real" 6Lo nodes which support 6Lo-ND according to RFC 6775 and nodes that only use 6Lo for IPv6 communication, such as ESP-NOW. Nodes that only use the 6Lo but do not support 6Lo-ND have to use SLAAC to get a valid link local address. That's why I suppose that there shouldn't be a problem to enable |
|
Looks like the fix might be as simple as #12683 |
You need
It is not, if I understood your question correctly... If SLAAC is enabled or not is decided in the NIB's config header for the most part. |
@miri64 Thanks. Now my picture of the world is all right again. |
@benpicco We should think about enabling |
If they are configured as advertising routers, prefixes should be advertised in the Router Advertisement's PIO. |
No, they aren't: |
|
That Readme hasn't been properly updated in a while… |
|
@benpicco Finally, I could test it. However, I could not get prefix delegation with my Speedport Hybrid. Therefore, I configured a DHCPv6 server on a separate Linux machine which delegates a sub-prefix of the Speedport Hybrid. After setting the route on the Speedport Hybrid by hand, the ESP-NOW node could ping GUAs. So the PR is good from my point of view. |
gschorcht
added
the
CI: ready for build
|
@miri64 Is the PR OK from your side? |
|
Can't reply to the comment directly, so answering here
Nothing prevents you from running UHCP on the upstream router / WiFi AP. |
I still think mentioning |
|
If we have other WiFi options we can come back and update the documentation. |
|
That said, it is good to mention that only esp32 and esp8466 platforms are currently supported for |
I just don't think the border router example is the right place for that. |
| credentials. You can alternatively edit the `Makefile`. | ||
|
|
||
| Currently, `wifi` requires an esp8266 or esp32 for the border router and will default | ||
| to using `esp_now` for the downstream interface. |
There was a problem hiding this comment.
You seem insistent to keep esp_now in... Fine, I'm not fighting about minor details such as this...
There was a problem hiding this comment.
I mean it is the default, so that should be documented.
This adds an example configuration to use the gnrc_border_router to route
between a regular WiFi network and an esp_now network.
All you need is an esp based board (esp8266, esp32).
Configure the access data for your WiFi network in `Makefile.esp.conf`,
then run
make BOARD=esp32-wroom-32 USE_ETHOS=0 USE_ESP=1 flash term
to turn a e.g. `esp32-wroom-32` into a boarder router.
You can use other esp based boards as nodes in the network by flashing
e.g. the `gnrc_networking` example.
Be sure to add `CFLAGS += -DGNRC_IPV6_NIB_CONF_SLAAC=1` as otherwise
your esp_now node will not receive a link-local IP address.
|
Please squash. |
|
(and fix the errors in the static tests, please) |
|
For those who squash too fast ;-) https://travis-ci.org/github/RIOT-OS/RIOT/builds/664597333#L163-L165 |
Contribution description
This adds an example configuration to use the
gnrc_border_routerto routebetween a regular WiFi network and an
esp_nownetwork.All you need is an esp based board (esp8266, esp32), an IPv6 uplink and a router that supports DHCPv6. Any OpenWRT router or Fritz!Box will do, make sure you have the relavant config opion enabled:
Testing procedure
Configure the access data for your WiFi network in
Makefile.esp.conf, then runto turn a e.g.
esp32-wroom-32into a boarder router.You can use other esp based boards as nodes in the network by flashing
e.g. the
gnrc_networkingexample.Be sure to add
CFLAGS += -DGNRC_IPV6_NIB_CONF_SLAAC=1as otherwiseyour esp_now node will not receive a link-local IP address.
It may take a couple of minutes before the border router has a global address on both interfaces, but then you should be able to ping global addresses from the esp_now nodes.
esp32-wroom-32esp8266-esp-12xIssues/PRs references
The border router is not very reliable. After a short while, routing may stop working, but it may also start working agaim.
There is also the occasional
on the border router or
on the node.