Hi,
at the f2f meeting today we Oleg proposed to have RPL run on the
border router as an alternative to [1] (since RPL always uses
link-local addresses as next hop, the neighbor cache would never be
asked for GUAs). This seemed to work (it ran for about 30 min), but we
(Cenk, Hauke and I) discussed that the manual configuration for RPL
currently needed is a big negative point in light of the fully
automated border router configuration. And while we could implement a
half-assed bootstapping mechanism until tomorrow, we decided against
this solution and stick with [1] for this release and have it done
properly instead with a proper interface bootstrapping/configuration
mechanism at some point in the future.
Cheers,
Martine
[1] https://github.com/RIOT-OS/RIOT/pull/5309
Out of mailing-list:
Hi Martin,
Regarding manual-configuration for RPL, the way contiki is doing it to prevent manual config on the border router is bypassing the network layers and doing kind of horrible things.
As I see most RIOT like a linux host, if I should do the same stuff dynamically I would be using ssh to configure the host with the adapted addresses/interfaces/routes.
Or a script run at startup wih configuration files.
So what about a RIOT shell script (with expect on the serial line?) to configure it "automatically with a manually run script".
This way, there could be a start_network script which would take care of everything automatically with manual configuration anyway.
So even if I would love to have RPL border routers now to use on IoT-LAB I agree with not bypassing the manual configuration in a quick-fix way.
Regards,
Gaëtan - IoT-LAB Team
Hi Gaetan,
(My name is Martine, not Martin). As for scripting: this would require
a shell and while it is currently available in most examples, this
isn't desirable (especially for in-network hosts and routers). A way
to statically configure the interfaces is preferable, because of that.
Martine