I *may* be jumping the gun here, but having just installed
5.4.0-1019-raspi this morning, things appear to be good!
Did an upgrade ~ 30 minutes ago (usually i find the issue is triggered
after around 10 minutes or so).
Will update if/when it crashes.
--
You received this bug notification be
Cancel that. As expected, issue still present.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-raspi2 in Ubuntu.
https://bugs.launchpad.net/bugs/1861936
Title:
Raspberry Pi 3 network dies shortly after a burst of IPv6 tunnel
net
I can confirm I am also seeing a very similar set of circumstances:
-Hardware name: Raspberry Pi 3 Model B Plus Rev 1.3 (DT)
-5.4.0-1015-raspi #15-Ubuntu SMP Fri Jul 10 05:34:24 UTC 2020 aarch64 aarch64
aarch64 GNU/Linux
-The "tunnel" in my case is using Wireguard to a server hosted externally.
-
Forgot to include:
Jul 28 18:18:25 dns1 kernel: [ 1289.970276] [ cut here ]
Jul 28 18:18:25 dns1 kernel: [ 1289.970354] NETDEV WATCHDOG: eth0 (lan78xx):
transmit queue 0 timed out
Jul 28 18:18:25 dns1 kernel: [ 1289.970463] WARNING: CPU: 1 PID: 0 at
net/sched/sch_generic
FWIW, i actually thought this was a bug with the latest raspbian image
and decided to move forward with using 20.04 on my raspberry pi's, turns
out that wasn't the case.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-raspi2 in Ubunt
I am also on a 3B+
ubuntu@dns1:~$ cat /proc/device-tree/model
Raspberry Pi 3 Model B Plus Rev 1.3
I dont believe you need anything fancy with IPv6, im not tunneling any v6 and
its occurring with me.
I do have IPv6 enabled on the interface used for tuneling.
Hui Wang, im happy to provide a shel
Absolutely!
--
My Raspberry Pi sits inside my home network, its config:
eth0:
IP: 192.168.200.11
GW: 192.168.200.1
IPv6: enabled (prefix delegation from ISP)
Metric: 300
wlan0:
IP: 192.168.209.11
GW: 192.168.209.1
IPv6: enabled (prefix delegation from ISP)
Metric: 400
wg0: flags=209
Forgot to include:
Raspberry PI:
ubuntu@dns1:~$ uname -a
Linux dns1 5.4.0-1022-raspi #25-Ubuntu SMP PREEMPT Thu Oct 15 13:31:49 UTC 2020
aarch64 aarch64 aarch64 GNU/Linux
ubuntu@dns1:~$
VPS:
root@m21:~# uname -a
Linux m21 5.4.0-52-generic #57-Ubuntu SMP Thu Oct 15 10:57:00 UTC 2020 x86_64
x86_6
And the most recent crash:
Oct 22 11:44:51 dns1 kernel: [ 3096.793118] [ cut here ]
Oct 22 11:44:51 dns1 kernel: [ 3096.793183] NETDEV WATCHDOG: eth0 (lan78xx):
transmit queue 0 timed out
Oct 22 11:44:51 dns1 kernel: [ 3096.793282] WARNING: CPU: 2 PID: 0 at
net/sched/sch_
So exactly what type of payload triggers the issues, that i cant work
out.
I know the traffic profile, vast majority of it is monitoring related as my VPS
is running grafana/influx and my internal clients are sending data over this
tunnel using telegraf.
There is also a fair bit of ICMP etc traf
RE IPv6, there is some manual config.
I have each vlan/network assigned a /64. On my pi's they get an address
in that /64 (different networks for eth0 and wlan0) but they do have a
static assignment as well (should have included that earlier:
interface eth0
metric 300
static ip6_address=2403:
@juergh I may have (somewhat) found the trigger.
As previously noted, my internal clients have a static route to the remote
wireguard networks via my raspberry pi. This is defined in my internal router
(Unifi)
ie:
client > router > static route (10.241.0.0/24) to pi eth0 IP > pi > tunnel > VPS
Ok yup this is almost certainly the issue (when the tunnel is pi is
tunnelling traffic for something other than itself)
My tunnel has been up for 12 hours, no crashes at all.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-raspi2 in
Well, it took more than 24 hours for my Pi to crash again, but it did
happen. I wasn't able to capture much of what triggered it as i wasn't
home at the time.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-raspi2 in Ubuntu.
https://
This has probably already been noticed, but in an attempt to simply get
my PI working somewhat the way i wanted, i changed my tunnel to run over
wlan0 instead of eth0 (they both connect back to the same network so
doesn't make a huge difference).
Tunnel and interfaces have been up for days, no iss
15 matches
Mail list logo
