gnrc_netif: centralize device-type-specific functions by miri64 · Pull Request #10524 · RIOT-OS/RIOT

miri64 · 2018-11-30T06:51:53Z

Contribution description

This moves all remaining switch (netif->device_type)-like functions to gnrc_netif_device_type.c and also applies the warning mechanisms introduced in #10513. The hope is that if a new device type is implemented the implementor will stumble over these functions basically immediately.

Testing procedure

Pinging a global address with gnrc_networking via a gnrc_border_router should still work for

Ethernet (here just two gnrc_networking examples with one having ifconfig <if> -rtr_adv and the other a global address configured by hand should be enough)
IEEE 802.15.4
Nordic BLE softdevice
~~cc110x~~ (see gnrc_ipv6_nib: 6Lo-ND EUI-64 checks not portable #10723)
~~nrfmin~~ (see gnrc_ipv6_nib: 6Lo-ND EUI-64 checks not portable #10723)
~~ESP NOW~~ (see gnrc_ipv6_nib: 6Lo-ND EUI-64 checks not portable #10723)

After pinging the global address of the other node, the neighbor cache (nib neigh) of the border router (or advertising router - so the one were you didn't type ifconfig <if> -rtr_adv) should contain the other node's global address with the correct link-layer address

Issues/PRs references

Depends on ~~#10513~~ (merged)

miri64 · 2018-12-03T14:44:11Z

Rebased and adapted for current #10513.

miri64 · 2018-12-04T20:04:36Z

sys/net/gnrc/netif/gnrc_netif_device_type.c

+#if defined(MODULE_CC110X)
+        case NETDEV_TYPE_CC110X:
+            (void)opt;
+            return sizeof(uint8_t);


I added this (in an extra commit), as it wasn't implemented yet.

miri64 · 2018-12-06T15:42:44Z

Rebased to current master. No longer dependent on another PR.

miri64 · 2018-12-06T18:54:00Z

Rebased again and squashed this time

miri64 · 2018-12-17T11:25:00Z

@maribu @gschorcht can you test this again?

miri64 · 2018-12-17T11:25:46Z

Maybe @aabadie can test for nordic softdevice and nrfmin (and all the rest :-))

gschorcht · 2018-12-17T13:54:35Z

@miri64 Tested.

After configuring 2001:db8::1 as global unicast address on the node with enabled RTR_ADV, the other node with disabled RTR_ADV gets the global unicast address 2001:db8::32ae:a4ff:fe18:7a3d. nib neigh on this gives:

> nib neigh
fe80::32ae:a4ff:fe41:60f9 dev #9 lladdr 30:AE:A4:41:60:F9 router REACHABLE
2001:db8::1 dev #9 lladdr 30:AE:A4:41:60:F9  REACHABLE

After pinging any global unicast address, nib neigh on the node with enabled RTR_ADV gives:

> nib neigh
fe80::32ae:a4ff:fe18:7a3d dev #9 lladdr 30:AE:A4:18:7A:3D router DELAY
2001:db8::32ae:a4ff:fe18:7a3d dev #9 lladdr 30:AE:A4:18:7A:3D  REACHABLE

I guess that is what you expected.

miri64 · 2018-12-17T14:01:43Z

Yepp :-)

miri64 · 2019-01-03T11:37:44Z

Rebased and adapted for current master.

miri64 · 2019-01-03T11:38:09Z

ESP-now needs retesting, since I needed to adopt for #10581.

maribu · 2019-01-07T17:24:36Z

Btw: Adding

if ! lsmod | grep tun > /dev/null ; then
    sudo modprobe tun
fi

To the script run on make term would make the developers life easier ;-)

maribu · 2019-01-07T17:40:22Z

OK, it does not work on the MSB-A2

This is what I did in example/gnrc_border_router:

make BOARD=msba2 PORT=/dev/ttyUSB0 flash
sudo modprobe tun
make BOARD=msba2 PORT=/dev/ttyUSB0 term

and in examples/gnrc_networking (while the border router was still running in a separate shell):

make BOARD=msba2 PORT=/dev/ttyUSB1 flash
make BOARD=msba2 PORT=/dev/ttyUSB1 term

But the MSB-A2 all get the same HW and IPv6 address. I changed the address on the board running examples/gnrc_netowrking after boot using:

ifconfig 7 del fe80::ff:fe00:22
ifconfig 7 add fe80::ff:fe00:42
ifconfig 7 set addr 42

miri64 · 2019-01-07T21:17:50Z

@maribu what does not work on MSB-A2? Your comment doesn't really provide any information on that :-/

miri64 · 2019-01-07T21:21:10Z

Btw: Adding
if ! lsmod | grep tun > /dev/null ; then
    sudo modprobe tun
fi
To the script run on make term would make the developers life easier ;-)

I believe you are the first one to report such a problem. I (with both Ubuntu and Arch) never had to load that module (nor add it to /etc/modules or something like that).

maribu · 2019-01-08T08:14:10Z

If I understood correctly, the boarder router should forward packets to the Internet. I did ping6 <IPv6_ADDRESS> and I only got a reply when I used the link lokal address of the border router, but not when pinging a global address. The output of nib neigh was empty at any time.

gschorcht · 2019-01-08T08:56:41Z

@maribu I guess your border router is connected to your LAN. Pinging global like 2a00:1450:4013:c07::5e from dig AAAA www.google.de requires that the way back is defined and you use a routable prefix for your 6LoWPAN. This would be the case, for example, when you use a subnet of the prefix that was assigned to your LAN from your ISP. In that case you could tell your router that a certain subnet is forwared to the border router LAN interface. Another test could be to define the route back to your border router on a machine in your LAN which you want to use as destination for your ping.

maribu · 2019-01-14T21:24:27Z

I just tested it with the current master and was unable to ping IPv6 addresses within my LAN. @miri64: Have you tried make term in the border router with the MSB-A2 lately? Could also be that the script is not compatible with Alpine Linux (even after modprobe tun). I'll give it a try with another Linux Distro as soon as I have time to check whether this is indeed an compatibility issue with Alpine.

miri64 · 2019-01-15T10:45:00Z

@maribu I tried on current master and there were two things I noticed when executing make term with the gnrc_border_router application on msba2:

it executes

sudo sh /home/mlenders/Repositories/RIOT-OS/RIOT/dist/tools/ethos/start_network.sh /dev/ttyUSB0 tap0 2001:db8::/64 -tg -p "/dev/ttyUSB0"

The last three parameters are wrong and don't belong there.

When executing
```
sudo sh /home/mlenders/Repositories/RIOT-OS/RIOT/dist/tools/ethos/start_network.sh /dev/ttyUSB0 tap0 2001:db8::/64
```
I still need to toggle the reset pins by hand (I did it by starting pyterm -tg -p /dev/ttyUSB0 and closing it immediately after). After that I can use the terminal of the border router (test with help)

After that I flashed and configured a second node (I removed lladdr fe80::ff:fe00:22 and set the hwaddr to 23 and added fe80::ff:fe00:23 and 2001:db8::ff:fe00:23). I then added a route to the other node on the BR (nib route add 7 2001:db8::/64 fe80::ff:fe00:23) (instead I could also just compile the border router with USEMODULE=gnrc_rpl).

Interestingly enough I am able to ping 2001:db8::ff:fe00:23 from the Linux host, but not the other way around (I suspect because the global address never becomes valid which hints to a not working neighbor discovery / address registration).

I confirmed that this is also works for this branch the same way. Since this the bug I reported above also is on current master, but the addresses and MTU are still configured correctly in this branch I'd say it works as expected (address registration doesn't seem to work but also not in master, so I investigate).

miri64 · 2019-01-15T11:53:24Z

I confirmed that this is also works for this branch the same way. Since this the bug I reported above also is on current master, but the addresses and MTU are still configured correctly in this branch I'd say it works as expected (address registration doesn't seem to work but also not in master, so I investigate).

Same problem as described in #10723.

miri64 · 2019-01-16T10:26:11Z

Addressed #10589 (comment)

cgundogan · 2019-01-16T11:00:24Z

sys/include/net/gnrc/netif/internal.h

+ * @brief   Get the default link-layer address option for the given
+ *          gnrc_netif_t::device_type of a network interface
+ */
+netopt_t gnrc_netif_get_l2addr_opt(gnrc_netif_t *netif);


Aren't @return and @param missing here, or did you left them out intentionally?

Good point! I also fixed some weird behavior (and the constness of parameter).

cgundogan

Tested successfully with ethernet and 15.4. Cannot test the softdevice at the moment. Nevertheless, IMO the code change shouldn't have an affect on the softdevice operation. ACK

cgundogan · 2019-01-16T14:49:03Z

addendum: please squash!

The function to infer the link-layer address length from the length of a S/TLLAO is very dependent on the IPv6 over X specification and thus should be grouped with the other IP over X functions.

miri64 · 2019-01-16T14:53:23Z

Squashed.

miri64 added Type: enhancement The issue suggests enhanceable parts / The PR enhances parts of the codebase / documentation Area: network Area: Networking Type: cleanup The issue proposes a clean-up / The PR cleans-up parts of the codebase / documentation labels Nov 30, 2018

miri64 requested a review from haukepetersen November 30, 2018 06:51

miri64 added the State: WIP State: The PR is still work-in-progress and its code is not in its final presentable form yet label Nov 30, 2018

miri64 force-pushed the gnrc_netif/enh/centralize-dev-type-functions branch from 2593e04 to cc0bc9c Compare November 30, 2018 08:04

miri64 added State: waiting for other PR State: The PR requires another PR to be merged first and removed State: WIP State: The PR is still work-in-progress and its code is not in its final presentable form yet labels Nov 30, 2018

This was referenced Nov 30, 2018

gnrc_netif: check all required options on initialization #10532

Merged

kw2xrf: Don't use netdev_ieee802154_t for link layer address #10534

Merged

net/gnrc_netif: opt of _ipv6_get_iid() #10455

Merged

miri64 force-pushed the gnrc_netif/enh/centralize-dev-type-functions branch from cc0bc9c to 84093cf Compare December 3, 2018 14:43

miri64 commented Dec 4, 2018

View reviewed changes

miri64 mentioned this pull request Dec 5, 2018

gnrc_netif: add general IID to/from l2addr conversion functions #10513

Merged

6 tasks

miri64 removed the State: waiting for other PR State: The PR requires another PR to be merged first label Dec 6, 2018

miri64 force-pushed the gnrc_netif/enh/centralize-dev-type-functions branch from 4849569 to ef0429e Compare December 6, 2018 15:42

miri64 force-pushed the gnrc_netif/enh/centralize-dev-type-functions branch from ef0429e to 43110bd Compare December 6, 2018 18:53

miri64 added the CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR label Dec 6, 2018

miri64 force-pushed the gnrc_netif/enh/centralize-dev-type-functions branch from 43110bd to 6c8f432 Compare December 6, 2018 20:15

miri64 mentioned this pull request Dec 11, 2018

l2util: initial import of a general IPv6 over X helper module #10589

Merged

miri64 force-pushed the gnrc_netif/enh/centralize-dev-type-functions branch from 6438b3b to 21261a8 Compare January 3, 2019 11:37

gnrc_netif: doc-group device-type based functions

465631f

miri64 force-pushed the gnrc_netif/enh/centralize-dev-type-functions branch from c066069 to 68bf1f5 Compare January 15, 2019 10:54

miri64 mentioned this pull request Jan 15, 2019

gnrc_ipv6: add sending DEBUG output #10769

Merged

cgundogan reviewed Jan 16, 2019

View reviewed changes

cgundogan approved these changes Jan 16, 2019

View reviewed changes

miri64 added 3 commits January 16, 2019 15:52

gnrc_netif: centralize S/TLLAO length to address length function

8f76353

The function to infer the link-layer address length from the length of a S/TLLAO is very dependent on the IPv6 over X specification and thus should be grouped with the other IP over X functions.

gnrc_netif: centralize function to get l2addr NETOPT

ea9bbd7

gnrc_netif: centralize function to init IPv6 MTU

55b9757

miri64 force-pushed the gnrc_netif/enh/centralize-dev-type-functions branch from 311b278 to 55b9757 Compare January 16, 2019 14:53

cgundogan merged commit b24a8fb into RIOT-OS:master Jan 16, 2019

miri64 deleted the gnrc_netif/enh/centralize-dev-type-functions branch January 16, 2019 15:45

maribu mentioned this pull request Jan 19, 2019

gnrc_ipv6_nib: use generated EUI-64 for ARO build and check #10817

Merged

aabadie added this to the Release 2019.01 milestone Jan 21, 2019

gschorcht mentioned this pull request Aug 6, 2020

examples/gnrc_border_router: esp_wifi crashes on disconnect #14679

Open

Conversation

miri64 commented Nov 30, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Contribution description

Testing procedure

Issues/PRs references

Uh oh!

miri64 commented Dec 3, 2018

Uh oh!

miri64 Dec 4, 2018

Choose a reason for hiding this comment

Uh oh!

miri64 commented Dec 6, 2018

Uh oh!

miri64 commented Dec 6, 2018

Uh oh!

miri64 commented Dec 17, 2018

Uh oh!

miri64 commented Dec 17, 2018

Uh oh!

gschorcht commented Dec 17, 2018

Uh oh!

miri64 commented Dec 17, 2018

Uh oh!

miri64 commented Jan 3, 2019

Uh oh!

miri64 commented Jan 3, 2019

Uh oh!

maribu commented Jan 7, 2019

Uh oh!

maribu commented Jan 7, 2019

Uh oh!

miri64 commented Jan 7, 2019

Uh oh!

miri64 commented Jan 7, 2019

Uh oh!

maribu commented Jan 8, 2019

Uh oh!

gschorcht commented Jan 8, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

maribu commented Jan 14, 2019

Uh oh!

miri64 commented Jan 15, 2019

Uh oh!

miri64 commented Jan 15, 2019

Uh oh!

miri64 commented Jan 16, 2019

Uh oh!

cgundogan Jan 16, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

miri64 Jan 16, 2019

Choose a reason for hiding this comment

Uh oh!

cgundogan left a comment

Choose a reason for hiding this comment

Uh oh!

cgundogan commented Jan 16, 2019

Uh oh!

miri64 commented Jan 16, 2019

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

miri64 commented Nov 30, 2018 •

edited

Loading

gschorcht commented Jan 8, 2019 •

edited

Loading

cgundogan Jan 16, 2019 •

edited

Loading