nrfmin: communication not possible after multicast ping with no interval

[miri64]

Description

While testing https://github.com/RIOT-OS/RIOT/pull/11395 I noticed that I can make the devices not respond to multicast pings anymore after I did a multicast ping with no interval (see https://github.com/RIOT-OS/RIOT/pull/11395#issuecomment-483582850).

Steps to reproduce the issue

From two nodes running nrfmin ping with multicast:

ping6 ff02::1 -c 1000 -i 10

You should be able to see at least some if not all replies.

Then start ping with interval zero on both nodes:

ping6 ff02::1 -c 10000 -i 0

After that try

ping6 ff02::1 -c 1000 -i 10

Expected results

The second

ping6 ff02::1 -c 1000 -i 10

should work as well as the first

Actual results

ping6 ff02::1 -c 1000 -i 10

Has 100% packet loss.

Versions

Current master (5e789c659584534ffb2e7eb9c86a56a9f6127dcf)

Operating System Environment
-----------------------------
       Operating System: "Ubuntu" "16.04.6 LTS (Xenial Xerus)"
                 Kernel: Linux 4.4.0-145-generic x86_64 x86_64

Installed compiler toolchains
-----------------------------
             native gcc: gcc (Ubuntu 5.4.0-6ubuntu1~16.04.11) 5.4.0 20160609
      arm-none-eabi-gcc: arm-none-eabi-gcc (GNU Tools for Arm Embedded Processors 7-2018-q3-update) 7.3.1 20180622 (release) [ARM/embedded-7-branch revision 261907]
                avr-gcc: avr-gcc (GCC) 4.9.2
       mips-mti-elf-gcc: mips-mti-elf-gcc (Codescape GNU Tools 2016.05-03 for MIPS MTI Bare Metal) 4.9.2
             msp430-gcc: msp430-gcc (GCC) 4.6.3 20120301 (mspgcc LTS 20120406 unpatched)
   riscv-none-embed-gcc: riscv-none-embed-gcc (GNU MCU Eclipse RISC-V Embedded GCC, 64-bits) 7.2.0
   xtensa-esp32-elf-gcc: xtensa-esp32-elf-gcc (crosstool-NG crosstool-ng-1.22.0-80-g6c4433a) 5.2.0
   xtensa-lx106-elf-gcc: xtensa-lx106-elf-gcc (crosstool-NG crosstool-ng-1.22.0-60-g37b07f6) 4.8.5
                  clang: clang version 3.8.0-2ubuntu4 (tags/RELEASE_380/final)

Installed compiler libs
-----------------------
   arm-none-eabi-newlib: "3.0.0"
    mips-mti-elf-newlib: "2.1.0"
riscv-none-embed-newlib: "2.5.0"
xtensa-esp32-elf-newlib: "2.2.0"
xtensa-lx106-elf-newlib: "2.0.0"
               avr-libc: "1.8.0svn" ("20111229")

Installed development tools
---------------------------
                  cmake: cmake version 3.12.0
               cppcheck: Cppcheck 1.72
                doxygen: 1.8.11
                 flake8: 2.5.4 (pep8: 1.7.0, mccabe: 0.2.1, pyflakes: 1.1.0) CPython 3.5.2 on Linux
                    git: git version 2.7.4
                   make: GNU Make 4.1
                openocd: Open On-Chip Debugger 0.10.0+dev-00676-g346ce2f (2019-02-04-16:44)
                 python: Python 2.7.12
                python2: Python 2.7.12
                python3: Python 3.5.2
             coccinelle: spatch version 1.0.4 with Python support and with PCRE support

[SemjonWilke]

I tried ping6 ff02::1 -c 1000 -i 10 on both nrfmin boards seperately and it did work multiple times. However sending pings the same way but simultaneously on both boards always resulted in 100% packet loss from that point on, in both cases sending simultaneously and seperately. Even without setting the interval to zero inbetween, I experienced the same bug.

In some cases resetting one board fixed the problem, but I did not find a reproduceable pattern.

[SemjonWilke]

So today I could reproduce the bug as you explained it. But at first when I tried your instructions, I could achieve the same result just by executing the first step, as I explained before.

I could fix the problem by resetting the board that started second with ping6 ff02::1 -c 10000 -i 0. So the problem probably resides within the receiver side, when trying to send packets while receiving and somehow breaking the states of the radio driver.