-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
gnrc_networking: run as host per default #21119
base: master
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change | ||||
---|---|---|---|---|---|---|
|
@@ -7,17 +7,22 @@ BOARD ?= native | |||||
# This has to be the absolute path to the RIOT base directory: | ||||||
RIOTBASE ?= $(CURDIR)/../.. | ||||||
|
||||||
# By default this application will run as a host, i.e., not forward any | ||||||
# packets. Setting this variable to 1 will change this behavior and let the | ||||||
# node act as a router. | ||||||
ROUTER ?= 0 | ||||||
# Include packages that pull up and auto-init the link layer. | ||||||
# NOTE: 6LoWPAN will be included if IEEE802.15.4 devices are present | ||||||
USEMODULE += netdev_default | ||||||
USEMODULE += auto_init_gnrc_netif | ||||||
# Activate ICMPv6 error messages | ||||||
USEMODULE += gnrc_icmpv6_error | ||||||
# Specify the mandatory networking module for a IPv6 routing node | ||||||
# Specify the mandatory networking module for a IPv6 in router or host node | ||||||
ifeq (1,$(ROUTER)) | ||||||
USEMODULE += gnrc_ipv6_router_default | ||||||
# Add a routing protocol | ||||||
USEMODULE += gnrc_rpl | ||||||
USEMODULE += auto_init_gnrc_rpl | ||||||
else | ||||||
USEMODULE += gnrc_ipv6_default | ||||||
endif | ||||||
# Additional networking modules that can be dropped if not needed | ||||||
USEMODULE += gnrc_icmpv6_echo | ||||||
USEMODULE += shell_cmd_gnrc_udp | ||||||
|
@@ -27,7 +32,16 @@ USEMODULE += shell_cmds_default | |||||
USEMODULE += ps | ||||||
USEMODULE += netstats_l2 | ||||||
USEMODULE += netstats_ipv6 | ||||||
|
||||||
# Optionally include the RPL routing protocol (particular useful if not all | ||||||
# nodes are within radio transmission range to the border router) | ||||||
USE_RPL ?= 0 | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
I see no reason (except that the border router is not automatically initialized as RPL root) to make this opt-in. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Hm, how often have you (or anyone else) used RPL with this example? The biggest arguments for disabling RPL here for meare reduced complexity and reduced code size. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
That's exactly my point. Everyone who uses this example currently uses RPL to a degree. Without it, the user base would shrink significantly, which would increase bit rot. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Not sure to which degree RPL is used in these scenarios (apart from trickle timers and the like). But I sense that we need a more general discussion with a broader range of the community about the purpose of this (and the other example applications) first. Currently, I would prefer this application as a simple host application and rather introduce a dedicated RPL example application. |
||||||
|
||||||
ifeq (1,$(USE_RPL)) | ||||||
USEMODULE += gnrc_rpl | ||||||
USEMODULE += auto_init_gnrc_rpl | ||||||
USEMODULE += netstats_rpl | ||||||
endif | ||||||
|
||||||
# Optionally include DNS support. This includes resolution of names at an | ||||||
# upstream DNS server and the handling of RDNSS options in Router Advertisements | ||||||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It still might be worth to have hosts in there as RPL leafs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you have any particular use case in mind?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well if you have a
gnrc_networking
router you might want it to also see the hosts (so they need to be a RPL leaf, i.e, keep thegnrc_rpl
modules in regardless ;-))There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also: IIRC this is currently our only real RPL example, so why remove it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, locally I have
examples/gnrc_networking_rpl
but that's not upstream (anymore?).Anyhow, I made it optional now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That was never upstream, it was part of #14623
But yea a dedicated RPL example would be better IMHO