Raspberry Pi 5 eth0 reports Link Up after Ethernet reconnect, but no traffic passes until reboot

Open
#7,345 8 comments 2 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
48/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Quiet
Tech stack
c, linux, raspberry-pi, ubuntu

Research direction

Start with the macb driver and BCM54213PE PHY path mentioned in the kernel logs, then reproduce the router-side unplug/replug sequence while comparing the failure and successful-boot logs. Check the networkctl, systemd-networkd, and kernel link-state messages; done means eth0 resumes ping, SSH, and other traffic after reconnecting without a reboot.

Written by the indexing model from the issue text.

Description

Close within 30 days
Describe the bug

On a Raspberry Pi 5 running Ubuntu 24.04.3 with the 6.8.0-1052-raspi kernel, unplugging and replugging the Ethernet cable from the router/switch side makes eth0 report that the link is back up at 1Gbps/full duplex, and the static IPv4 address is registered again, but no traffic passes until the Pi is rebooted.

After the reconnect, the Pi is not reachable from another machine on the same LAN via ping or SSH. The Pi also logs NTP timeouts after the link is supposedly back up, which suggests the Pi itself cannot pass traffic either.

I know this is reproduced on Ubuntu rather than Raspberry Pi OS, so if Launchpad / Ubuntu linux-raspi is the preferred place for this report, please let me know. I am filing it here first because the symptoms look like they may involve the Raspberry Pi 5 Ethernet/macb/PHY path.

Environment
  • Device: Raspberry Pi 5
  • OS: Ubuntu 24.04.3 LTS
  • Kernel: 6.8.0-1052-raspi #56-Ubuntu SMP PREEMPT_DYNAMIC Fri Mar 27 03:58:47 UTC 2026 aarch64
  • systemd: 255.4-1ubuntu8.14
  • Network stack: netplan + systemd-networkd
  • Interface: eth0
  • Driver shown by networkctl: macb
  • PHY shown in kernel logs: Broadcom BCM54213PE
  • IPv4: static 192.168.0.4/24, gateway 192.168.0.1
  • Power/throttling check: vcgencmd get_throttled returns throttled=0x0
Steps to reproduce
  1. Boot the Raspberry Pi 5 with Ethernet connected.
  2. Confirm it is reachable from another host on the same LAN:
    • ping 192.168.0.4
    • SSH also works.
  3. Unplug the Ethernet cable from the router/switch side only. Do not touch the Pi side.
  4. Wait a few seconds.
  5. Plug the cable back into the router/switch.
  6. Observe that the Pi logs Link is Up and Gained carrier, and the static IPv4 address is registered again.
  7. Try to ping or SSH into the Pi from another LAN host.
  8. Reboot the Pi.
  9. Observe that connectivity returns immediately after reboot.
Expected behaviour

After the Ethernet cable is reconnected, eth0 should resume passing traffic without requiring a reboot.

Actual behaviour

After reconnecting Ethernet:

  • eth0 reports Link is Up - 1Gbps/Full.
  • systemd-networkd reports Gained carrier.
  • The static IPv4 address is registered again.
  • But no traffic passes until reboot.
  • Another LAN host cannot ping or SSH into the Pi.
  • The Pi logs NTP timeouts after the reconnect.
Relevant logs

Failure case after reconnect:

May 01 19:08:31 pi5 systemd-networkd[670]: eth0: Lost carrier
May 01 19:08:31 pi5 kernel: macb 1f00100000.ethernet eth0: Link is Down
May 01 19:08:31 pi5 systemd-networkd[670]: eth0: DHCPv6 lease lost
May 01 19:08:31 pi5 avahi-daemon[714]: Withdrawing address record for 192.168.0.4 on eth0.
May 01 19:08:31 pi5 systemd-timesyncd[555]: No network connectivity, watching for changes.
May 01 19:08:34 pi5 systemd-networkd[670]: eth0: Gained carrier
May 01 19:08:34 pi5 kernel: macb 1f00100000.ethernet eth0: Link is Up - 1Gbps/Full - flow control tx
May 01 19:08:34 pi5 systemd-networkd[670]: eth0: found matching network '/run/systemd/network/10-netplan-eth0.network', based on potentially unpredictable interface name.
May 01 19:08:34 pi5 systemd-timesyncd[555]: Network configuration changed, trying to establish connection.
May 01 19:08:34 pi5 avahi-daemon[714]: Registering new address record for 192.168.0.4 on eth0.IPv4.
May 01 19:08:44 pi5 systemd-timesyncd[555]: Timed out waiting for reply from 91.189.91.157:123 (ntp.ubuntu.com).
May 01 19:08:55 pi5 systemd-timesyncd[555]: Timed out waiting for reply from 185.125.190.58:123 (ntp.ubuntu.com).

Successful boot after reboot:

May 01 19:14:03 pi5 systemd-networkd[671]: eth0: Link UP
May 01 19:14:07 pi5 kernel: macb 1f00100000.ethernet eth0: Link is Up - 1Gbps/Full - flow control tx
May 01 19:14:07 pi5 systemd-networkd[671]: eth0: Gained carrier
May 01 19:14:08 pi5 cloud-init[681]: ci-info: |  eth0  |  True |         192.168.0.4         | 255.255.255.0 | global | [redacted] |
May 01 19:14:09 pi5 avahi-daemon[715]: Registering new address record for 192.168.0.4 on eth0.IPv4.
Things already tested
  • Static IPv4 instead of DHCPv4: issue still reproduces.
  • Different Ethernet cable: issue still reproduces.
  • Different router LAN port: issue still reproduces.
  • Rebooting restores network immediately.
  • apt full-upgrade reports the running kernel is up to date.
  • No undervoltage/throttling flags: throttled=0x0.
Additional note

There was also a separate case where the Pi logged Power key pressed short when physically touching the Pi-side cabling/case. That appears to be a separate case/button interaction issue. The Ethernet reconnect issue described here is reproduced by unplugging/replugging only the router/switch-side cable, without touching the Pi.

Dominant language
C
Stars
13.2k
Forks
5.5k
Avg merge
2d 21h
Merged PRs (30d)
21

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from raspberrypi/linux

All issues in raspberrypi/linux

Similar issues

More C issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.