You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When building the gnrc_networking example for native, it is interfering with the forwarding rules on the host machine. The reason seems to be that the pseudo-module gnrc_ipv6_router_default will cause the RIOT instance to send out router advertisements (RA). The Linux host receiving the RAs via the bridge interface will add the RIOT instance as a default gateway.
I'm not quite sure whether it is valid behavior of an IPv6 router to announce itself as a router without having an actually routable IPv6 address. In any case this behavior leads to a non-functional IPv6 setup on the host machine.
Steps to reproduce the issue
Use latest RIOT master branch.
Build and run the gnrc_networking example for native or native64.
Wait some time and monitor the Linux kernel IPv6 routing table (e.g., via watch ip -6 r)
Expected results
Only actual useful RAs are sent/processed by the Linux host. (I.e., if it is actually correct behavior of the RIOT router to send the RAs without a routable address we may want to filter them somehow.
Actual results
Additional default routes (depending on the number of native instances) will show up.
Versions
Operating System Environment
----------------------------
Operating System: "Arch Linux"
Kernel: Linux 6.9.10-arch1-1 x86_64 unknown
System shell: GNU bash, version 5.2.26(1)-release (x86_64-pc-linux-gnu)
make's shell: GNU bash, version 5.2.26(1)-release (x86_64-pc-linux-gnu)
Installed compiler toolchains
-----------------------------
native gcc: gcc (GCC) 14.1.1 20240522
arm-none-eabi-gcc: arm-none-eabi-gcc (Arch Repository) 14.1.0
avr-gcc: avr-gcc (GCC) 14.1.0
msp430-elf-gcc: msp430-elf-gcc (GCC) 13.1.0
riscv-none-elf-gcc: missing
riscv64-unknown-elf-gcc: missing
riscv32-esp-elf-gcc: missing
xtensa-esp32-elf-gcc: xtensa-esp32-elf-gcc (crosstool-NG crosstool-ng-1.22.0-80-g6c4433a) 5.2.0
xtensa-esp32s2-elf-gcc: missing
xtensa-esp32s3-elf-gcc: missing
xtensa-esp8266-elf-gcc: missing
clang: clang version 18.1.8
Installed compiler libs
-----------------------
arm-none-eabi-newlib: "4.4.0"
msp430-elf-newlib: "4.3.0"
riscv-none-elf-newlib: missing
riscv64-unknown-elf-newlib: missing
riscv32-esp-elf-newlib: missing
xtensa-esp32-elf-newlib: "2.2.0"
xtensa-esp32s2-elf-newlib: missing
xtensa-esp32s3-elf-newlib: missing
xtensa-esp8266-elf-newlib: missing
avr-libc: "2.2.0" ("20240608")
Installed development tools
---------------------------
ccache: ccache version 4.10
cmake: cmake version 3.30.1
cppcheck: missing
doxygen: 1.11.0
git: git version 2.45.2
make: GNU Make 4.4.1
openocd: Open On-Chip Debugger 0.12.0
python: Python 3.12.4
python2: Python 2.7.18
python3: Python 3.12.4
flake8: 7.1.0 (mccabe: 0.7.0, pycodestyle: 2.11.1, pyflakes: 3.2.0) CPython 3.12.4 on
coccinelle: missing
The text was updated successfully, but these errors were encountered:
Description
When building the
gnrc_networking
example for native, it is interfering with the forwarding rules on the host machine. The reason seems to be that the pseudo-modulegnrc_ipv6_router_default
will cause the RIOT instance to send out router advertisements (RA). The Linux host receiving the RAs via the bridge interface will add the RIOT instance as a default gateway.I'm not quite sure whether it is valid behavior of an IPv6 router to announce itself as a router without having an actually routable IPv6 address. In any case this behavior leads to a non-functional IPv6 setup on the host machine.
Steps to reproduce the issue
gnrc_networking
example for native or native64.watch ip -6 r
)Expected results
Only actual useful RAs are sent/processed by the Linux host. (I.e., if it is actually correct behavior of the RIOT router to send the RAs without a routable address we may want to filter them somehow.
Actual results
Additional default routes (depending on the number of native instances) will show up.
Versions
The text was updated successfully, but these errors were encountered: