Alexander Aring created two patches that fix this problem.
Details can be found here:
Steps to reproduce "skb_over_panic" kernel panic when sending a simple UDP packet over a 6lowpan interface (using fakelb).
Verified with the following kernels:
- Linux version 4.9.0-0.bpo.2-amd64 ([email protected]) (gcc version 4.9.2 (Debian 4.9.2-10) ) #1 SMP Debian 4.9.13-1~bpo8+1 (2017-02-27) (x86_64)
- Linux version 4.10.4-1-ARCH (builduser@tobias) (gcc version 6.3.1 20170306 (GCC) ) #1 SMP PREEMPT Sat Mar 18 19:39:18 CET 2017 (x86_64)
- Linux version 4.10.5-1-ARCH (builduser@tobias) (gcc version 6.3.1 20170306 (GCC) ) #1 SMP PREEMPT Wed Mar 22 14:42:03 CET 2017 (x86_64)
Note: Could not reproduce it with 32-bit architectures!
Works fine on Debian with the following kernel:
- Linux version 4.9.0-0.bpo.2-686 ([email protected]) (gcc version 4.9.2 (Debian 4.9.2-10) ) #1 SMP Debian 4.9.13-1~bpo8+1 (2017-02-27) (i686)
Works fine on a Raspberry Pi 3, running Arch Linux ARM (32&64bit), with any of the following kernels:
- Linux version 4.10.6-1-ARCH (builduser@leming) (gcc version 6.3.1 20170306 (GCC) ) #1 SMP Sun Mar 26 15:42:21 MDT 2017 (aarch64)
- 4.9.17-1-ARCH (from alarm repositories)
- 4.10.5-v7+ built from source (using https://github.com/raspberrypi/linux/tree/rpi-4.10.y)
- 4.11.0-rc3-v7+ built from source (using https://github.com/raspberrypi/linux/tree/rpi-4.11.y)
As root run (root permissions are needed for loading/removing the fakelb module):
./setup_wpan.sh
This script will try to remove the fakelb module, load it with two lbs (wpan0 and wpan1), and create two namespaces for each lb (again wpan0 and wpan1), adding a lowpan link (lowpan0 and lowpan1) with the IP addresses b:1::1 and b:1::2 .
./test_ping b:1::1 (or b:1::2)
ip netns exec wpan0 ping6 -s 39 b:1::2
or
ip netns exec wpan1 ping6 -s 39 b:1::1
This command should be run by a user with permissions to manage namespaces, but the actual sending of the UDP packets does not require any special privileges:
ip netns exec wpan0 runuser -l user -c "python ./send_udp_packet.py"
or simply:
ip netns exec wpan0 "python ./send_udp_packet.py"
I can't explain this but, when SSHing real hardware and making it fail with the above setup, connectivity is lost on all machines connected to the same hub. Looking deeper into the matter, a tcpdump revealed the generation of MAC CTRL packets looking like this:
[no.] [time] [source] Spanning-tree-(for-bridges)_01 MAC CTRL 60 Pause: pause_time: 65535 quanta