Skip to content

ethos: Unable to handle fragmented IPv6 packets from Linux kernel #12264

Open
@miri64

Description

Description

When testing #11596 we noticed, that ethos was unable to handle fragmented IPv6 packets. We saw them in wireshark but some fragments weren't able to be passed to the IPv6 layer. Sometimes all fragments were dropped, sometimes only the second (of two).

Steps to reproduce the issue

Remove the early exit of the gnrc_ipv6_ext_frag tests for non-native boards

diff --git a/tests/gnrc_ipv6_ext_frag/tests/01-run.py b/tests/gnrc_ipv6_ext_frag/tests/01-run.py
index 8fa7c1341f..87a1530db3 100755
--- a/tests/gnrc_ipv6_ext_frag/tests/01-run.py
+++ b/tests/gnrc_ipv6_ext_frag/tests/01-run.py
@@ -353,13 +353,6 @@ def testfunc(child):
         run_sock_test(test_ipv6_ext_frag_fwd_success, s)
         run_sock_test(test_ipv6_ext_frag_fwd_too_big, s)
 
-    if os.environ.get("BOARD", "") != "native":
-        # ethos currently can't handle the larger, rapidly sent packets by the
-        # IPv6 fragmentation of the Linux Kernel
-        print("SUCCESS")
-        print("Skipping datagram reception tests due to ethos bug.")
-        return
-
     # datagram reception tests
     res = 1
     count = 0

Compile and flash the application to a non-native board of your choice and run the test (I recommend to also have a wireshark running on the ethos interface during the tests)

BOARD=samr21-xpro make -C tests/gnrc_ipv6_ext_frag/ flash
sudo BOARD=samr21-xpro make -C tests/gnrc_ipv6_ext_frag/ test

Expected results

The tests pass, all fragmented datagrams sent from the Linux side are received by the RIOT node.

Actual results

The fragmented datagrams sent by the Linux kernel are not received, as fragments get lost somewhere in the ethos layer. If we look into wireshark, however, we actually see a fragmented datagram going in (frames 34 and 35 in my screenshot).

image

Versions

Current master (5631b69)

Operating System Environment
-----------------------------
       Operating System: "Ubuntu" "19.04 (Disco Dingo)"
                 Kernel: Linux 5.0.0-27-generic x86_64 x86_64

Installed compiler toolchains
-----------------------------
             native gcc: gcc (Ubuntu 8.3.0-6ubuntu1) 8.3.0
      arm-none-eabi-gcc: arm-none-eabi-gcc (GNU Tools for Arm Embedded Processors 8-2018-q4-major) 8.2.1 20181213 (release) [gcc-8-branch revision 267074]
                avr-gcc: avr-gcc (GCC) 5.4.0
       mips-mti-elf-gcc: missing
             msp430-gcc: msp430-gcc (GCC) 4.6.3 20120301 (mspgcc LTS 20120406 unpatched)
   riscv-none-embed-gcc: missing
   xtensa-esp32-elf-gcc: missing
   xtensa-lx106-elf-gcc: missing
                  clang: clang version 8.0.0-3 (tags/RELEASE_800/final)

Installed compiler libs
-----------------------
   arm-none-eabi-newlib: "3.0.0"
    mips-mti-elf-newlib: missing
riscv-none-embed-newlib: missing
xtensa-esp32-elf-newlib: missing
xtensa-lx106-elf-newlib: missing
               avr-libc: "2.0.0" ("20150208")

Installed development tools
---------------------------
                  cmake: cmake version 3.13.4
               cppcheck: missing
                doxygen: 1.8.13
                    git: git version 2.20.1
                   make: GNU Make 4.2.1
                openocd: Open On-Chip Debugger 0.10.0+dev-00910-g4dbcb1e7 (2019-06-17-16:24)
                 python: Python 2.7.16
                python2: Python 2.7.16
                python3: Python 3.7.3
                 flake8: 3.6.0 (mccabe: 0.6.1, pycodestyle: 2.4.0, pyflakes: 2.0.0) CPython 3.7.3 on Linux
             coccinelle: missing

Metadata

Labels

Area: driversArea: Device driversArea: networkArea: NetworkingArea: toolsArea: Supplementary toolsType: bugThe issue reports a bug / The PR fixes a bug (including spelling errors)

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions