| 2020-12-17 07:41:17 |
Juerg Haefliger |
description |
When testing 20.04.1, I noticed some different behavior on rpi3b+ that I didn't see on rpi3b or rpi4. I have configured the device with ethernet, added netplan yaml for my wifi network, and rebooted. So both eth0 and wlan0 have an ip address.
On all other devices (rpi3b, rpi4, etc), if I unplug eth0 wile pinging something, I'll miss maybe 1 ping and then it will continue to work and just switch over to wlan0. However, on rpi3b+ it just stops being able to access the network completely. If I re-run netplan apply, it will start using wifi again, but if I plug eth0 back in, then unplug it, it stops just like before.
I am seeing this with the current 20.04.1 release:
Linux ubuntu 5.4.0-1015-raspi #15-Ubuntu SMP Fri Jul 10 05:34:24 UTC 2020 aarch64 aarch64 aarch64 GNU/Linux
I also went back and tested the original 20.04 release and it happens there too, so this is not a regression:
Linux ubuntu 5.4.0-1008-raspi #8-Ubuntu SMP Wed Apr 8 11:13:06 UTC 2020 aarch64 aarch64 aarch64 GNU/Linux
I see this happen on both armhf and arm64. One difference I did note, is that I get a link down message in dmesg on rpi3b, but not rpi3b+. When I disconnect eth0 on rpi3b I see this:
[ 82.203702] smsc95xx 1-1.1:1.0 eth0: link down
...but nothing on the 3b+. |
[Impact]
When testing 20.04.1, I noticed some different behavior on rpi3b+ that I didn't see on rpi3b or rpi4. I have configured the device with ethernet, added netplan yaml for my wifi network, and rebooted. So both eth0 and wlan0 have an ip address.
On all other devices (rpi3b, rpi4, etc), if I unplug eth0 wile pinging something, I'll miss maybe 1 ping and then it will continue to work and just switch over to wlan0. However, on rpi3b+ it just stops being able to access the network completely. If I re-run netplan apply, it will start using wifi again, but if I plug eth0 back in, then unplug it, it stops just like before.
I am seeing this with the current 20.04.1 release:
Linux ubuntu 5.4.0-1015-raspi #15-Ubuntu SMP Fri Jul 10 05:34:24 UTC 2020 aarch64 aarch64 aarch64 GNU/Linux
I also went back and tested the original 20.04 release and it happens there too, so this is not a regression:
Linux ubuntu 5.4.0-1008-raspi #8-Ubuntu SMP Wed Apr 8 11:13:06 UTC 2020 aarch64 aarch64 aarch64 GNU/Linux
I see this happen on both armhf and arm64. One difference I did note, is that I get a link down message in dmesg on rpi3b, but not rpi3b+. When I disconnect eth0 on rpi3b I see this:
[ 82.203702] smsc95xx 1-1.1:1.0 eth0: link down
...but nothing on the 3b+.
[Test Case]
Disconnect and reconnect the eth0 cable. The link will not come back up. Or down eth0 and bring it back up. The link will not come back up.
$ ip a
...
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether b8:27:eb:3e:ab:fb brd ff:ff:ff:ff:ff:ff
inet 192.168.99.191/24 brd 192.168.99.255 scope global dynamic eth0
valid_lft 795197sec preferred_lft 795197sec
inet6 fe80::ba27:ebff:fe3e:abfb/64 scope link
valid_lft forever preferred_lft forever
...
$ ip link set eth0 down
$ ip link set eth0 up
$ ip a
...
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether b8:27:eb:3e:ab:fb brd ff:ff:ff:ff:ff:ff
...
[Where problems could occur]
The fix is to read the PHY status register to clear pending interrupts. That read could fail for various reasons which would probably result in kernel error messages. But nothing more should happen. IMO worst case is that we get the old behavior. |
|
