examples/gnrc_minimal: minimalize gnrc_minimal example

[miri64]

Contribution description

Inspired by 9103e5b I looked and checked if the gnrc_minimal example also has LOG_LEVEL=LOG_NONE set. And in fact it hasn't. So I activated it. While I was minimizing around, I noticed that DEVELHELP was activated for this minimal example. This change goes way back to a change by @kYc0o in abf6c3e (#6406)... Apparently, I didn't look into the details of this example for a while now... IMHO the logic for this should be the other way around, due to the minimalized nature of that example: DEVELHELP=0, but the comment should provide help what to do to gain its advantages.

Testing procedure

Compile examples/gnrc_minimal. It should now be significantly smaller than without these changes.

Issues/PRs references

None

[miri64]

I hope the comment makes sense now ^^"

[benpicco]

I agree with the changes in this PR, but I just tried gnrc_minimal on the microduino-corerf (ATmega128RFA1), the other node is running gnrc_networking.
I did ping6 ff02::1:

• stock configuration: no response.
• changed USEMODULE += gnrc_ipv6 to USEMODULE += gnrc_ipv6_router_default: no response
• removed CFLAGS += -DGNRC_PKTBUF_SIZE=512 -DGNRC_NETIF…: no response
• changed USEMODULE += gnrc_ipv6 to USEMODULE += gnrc_ipv6_router_default and removed CFLAGS += -DGNRC_PKTBUF_SIZE=512 -DGNRC_NETIF…:

2019-10-25 00:46:17,715 # 12 bytes from fe80::863d:27a0:3c22:843e: icmp_seq=0 ttl=64 rssi=-71 dBm time=8.095 ms
2019-10-25 00:46:18,715 # 12 bytes from fe80::863d:27a0:3c22:843e: icmp_seq=1 ttl=64 rssi=-70 dBm time=8.095 ms
2019-10-25 00:46:19,714 # 12 bytes from fe80::863d:27a0:3c22:843e: icmp_seq=2 ttl=64 rssi=-70 dBm time=7.776 ms
2019-10-25 00:46:19,715 # 
2019-10-25 00:46:19,717 # --- ff02::1 PING statistics ---
2019-10-25 00:46:19,722 # 3 packets transmitted, 3 packets received, 0% packet loss
2019-10-25 00:46:19,726 # round-trip min/avg/max = 7.776/7.988/8.095 ms

[miri64]

So none of that has to do with the proposed changes, but the application is broken in itself?

[miri64]

What was your network interface?

[miri64]

Ah... 6LoWPAN IPHC and fragmentation are not compiled in (on purpose). That is why you can't ping the gnrc_minimal application. Try ifconfig <if> -iphc on the gnrc_networking node.

[benpicco]

Ah that is it!
After ifconfig <if> -iphc the ping works.

So while you are minimizing this example, please maximize the documentation so it doesn't seem to be broken for the unsuspecting user.

[miri64]

Isn't the Readme enough? https://github.com/RIOT-OS/RIOT/tree/master/examples/gnrc_minimal

[benpicco]

Oh it's already right there! 😅
Sorry for the noise.

My only complaints unrelated to this PR are

• it's not intuitive that header compression is related to the gnrc_ipv6_router_default module
• could the nib contain a flag whether a neighbour supports header compression or not?

[benpicco]

Disabling debug options makes sense for a example in minimalism.

review issues are resolved

[benpicco]

Please squash!

[miri64]

My only complaints unrelated to this PR are

• it's not intuitive that header compression is related to the gnrc_ipv6_router_default module

Indeed it isn't and it is only incidental. gnrc_ipv6_router_default (or its small, non-forwarding sibling gnrc_ipv6_default) pull in all dependencies to have a fully working IPv6 protocol (up to the respective RFCs). For radios that need it, this also pulls in gnrc_sixlowpan_router_default (or gnrc_sixlowpan_default respectively), which in turn does the same for 6LoWPAN (so also pulls in IPHC if the IPv6-over-X RFC demands it). Doc on that exists in the GNRC documentation.

• could the nib contain a flag whether a neighbour supports header compression or not?

It could, but how would that be propagated is not specified (I think it is just assumed IPHC is in place for every IPv6-over-IEEE802.15.4 capable node). The 6CO option (not supported by RIOT yet) only indicates if GHC is supported so far.

[miri64]

Squashed

[miri64]

• could the nib contain a flag whether a neighbour supports header compression or not?

It could, but how would that be propagated is not specified (I think it is just assumed IPHC is in place for every IPv6-over-IEEE802.15.4 capable node). The 6CO option (not supported by RIOT yet) only indicates if GHC is supported so far.

PS: this also would add complexity to the node which we are trying to avoid ;-).

[miri64]

Let's see how it fairs during the nightlies :-)