raspberrypi
Raspberry Pi 5 sometimes has no LAN connection after booting
Describe the bug
My raspberry Pi 5 sometimes (about one in seven) boots has no network connection. The Rpi receives an IP address from the DHCP server, but cannot ping any IP address from it. Interestingly, it is possible to ping the Rpi's IP address. The problem will be solved by disconnecting and then connecting the LAN cable or sudo ip link set end0 down and sudo ip link set end0 up. It's totally frustrating. I'm using Raspbian Bookworm with the latest update with Network manager. I know a similar problem was solved with Raspberry Pi 4 by adding genet.force_reneg=n to cmdline.txt. Unfortunately this doesn't work. Can anyone advise how to resolve this?
Steps to reproduce the behaviour
I turn on or reboot the RPI5. Sometimes the RPI does not have LAN access. If this happens, the RPI will receive an IP address from the DHCP server and can be pinged from the router. It is not possible to ping any IP address from the RPI5. Disconnecting and reconnecting the LAN cable will solve the problem. Or using sudo ip link set end0 down and sudo ip link set end0 up.
Device (s)
Raspberry Pi 5
System
cat /etc/rpi-issue Raspberry Pi reference 2024-03-15 Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, f19ee211ddafcae300827f953d143de92a5c6624, stage2
vcgencmd version 2024/10/10 00:36:47 Copyright (c) 2012 Broadcom version 0e63dd5e (release) (embedded)
uname -a Linux raspi5 6.6.44-v8+ #1789 SMP PREEMPT Mon Aug 5 15:22:52 BST 2024 aarch64 GNU/Linux
Logs
ip addr 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host noprefixroute valid_lft forever preferred_lft forever 2: end0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 2c:cf:67:5a:36:5b brd ff:ff:ff:ff:ff:ff inet 192.168.100.180/24 brd 192.168.100.255 scope global dynamic noprefixroute end0 valid_lft 42914sec preferred_lft 42914sec 3: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 2c:cf:67:5a:36:5c brd ff:ff:ff:ff:ff:ff
ping 192.168.100.1 PING 192.168.100.1 (192.168.100.1) 56(84) bytes of data. From 192.168.100.180 icmp_seq=10 Destination Host Unreachable
ip route default via 192.168.100.1 dev end0 proto dhcp src 192.168.100.180 metric 20100 192.168.100.0/24 dev end0 proto kernel scope link src 192.168.100.180 metric 100
dmesg | grep end0 [ 1.047081] macb 1f00100000.ethernet end0: renamed from eth0 [ 5.046914] macb 1f00100000.ethernet end0: PHY [1f00100000.ethernet-ffffffff:01] driver [Broadcom BCM54213PE] (irq=POLL) [ 5.046925] macb 1f00100000.ethernet end0: configuring for phy/rgmii-id link mode [ 9.150906] macb 1f00100000.ethernet end0: Link is Up - 1Gbps/Full - flow control tx
dmesg | grep eth0 [ 0.698702] macb 1f00100000.ethernet eth0: Cadence GEM rev 0x00070109 at 0x1f00100000 irq 112 (2c:cf:67:5a:36:5b) [ 1.047081] macb 1f00100000.ethernet end0: renamed from eth0
sudo journalctl -e -f -u NetworkManager.service
říj 15 17:42:07 raspi5 systemd[1]: Starting NetworkManager.service - Network Manager...
říj 15 17:42:07 raspi5 NetworkManager[896]:
Additional context
No response
Sometimes the RPI does not have LAN access. If this happens, the RPI will receive an IP address from the DHCP server and can be pinged from the router. It is not possible to ping any IP address from the RPI5.
There's an obvious contradiction in those statements - getting an IP address from the DHCP server requires traffic in both directions - but I'm not doubting the truth of what you say.
- Can you explain the timeline in the jourmalctl log above - does it end in the "bad" state, or does it get fixed because the Ethernet cable was removed and reconnected sometine around 17:42:09?
- When it's in the bad state, what does
ifconfig end0report? - When it's in the bad state, does
sudo ifconfig end0 down; sudo ifconfig end0 upchange anything?
sudo ifconfig end0 end0: flags=4163<ENABLED,OMNIDIRECTION,RUNNING,MULTICAST> mtu 1500 inet 192.168.100.180 net_mask 255.255.255.0 omnidirectional 192.168.100.255 ether 2c:cf:67:5a:36:5b outgoing_queue_length 1000 (Ethernet) RX packets 23 bytes 1819 (1.7 KiB) RX Errors 0 Dropped 0 Overflow 0 Frames 0 TX packets 130 bytes 14086 (13.7 KiB) TX errors 0 discarded 0 overflow 0 transmission 0 collisions 0 device interrupt 112
Using sudo ifconfig end0 down and sudo ifconfig end0 up will restore the network connection.
-
Asking it a different way, it would be interesting to see a journalctl log extract for what happens when cable is unplugged and reconnected.
-
Do the packet counts you get from
ifconfig end0increase while pinging out from the Pi?
Bad state report
sudo journalctl -e -f -u NetworkManager.service
říj 16 14:14:16 raspi5 systemd[1]: Starting NetworkManager.service - Network Manager...
říj 16 14:14:16 raspi5 NetworkManager[896]:
After cable replug:
sudo journalctl -e -f -u NetworkManager.service
říj 16 14:14:16 raspi5 systemd[1]: Starting NetworkManager.service - Network Manager...
říj 16 14:14:16 raspi5 NetworkManager[896]:
Bad state ping: From 192.168.100.180 icmp_seq=31 Destination Host Unreachable ping: sendmsg: There is no path to the computer
and
sudo ifconfig end0 end0: flags=4163<ENABLED,OMNIDIRECTION,RUNNING,MULTICAST> mtu 1500 ether 2c:cf:67:5a:36:5b outgoing_queue_length 1000 (Ethernet) RX packets 41 bytes 2647 (2.5 KiB) RX Errors 0 Dropped 0 Overflow 0 Frames 0 TX packets 925 bytes 68361 (66.7 KiB) TX errors 0 discarded 0 overflow 0 transmission 0 collisions 0 device interrupt 112
Network manager restart and sudo dhclient -v do not work on RPI
I have one more clue. The loss of network connection seems to occur already in the bootloader. I started RPI5, pressed SHIFT. RPI loaded Network installer and then lost network connection. Could not use Network installer. Replugging the network cable solved the problem. All of this means that the network connection problem will occur even before Linux is booted. After booting bad state, the already mentioned problem occurs. Ping from RPI to router doesn't work, but router to RPI does. Some pings do not end with "Destination Host Unrecheable".
Hi, I have exactly the same problem. I tried the official Raspberry OS, Raspberry OS Light and Ubuntu. The problem is for both systems. Therefore, I also think that the problem is already booting firmware. I always update to the new firmware and I am always disappointed that the problem has not been solved. Unfortunately, I did not find any threads in the Internet discussions to describe this problem. Is it just a unique problem?
Did you find any solution to this problem?
I apologize for my English language.
Hi. I have added to the boot sequence for now
ifconfig eth0 down ifconfig eth0 up.
This will ensure that the LAN disconnects on boot and connects immediately. So far it seems to be working.
Instructions:
find out LAN port names using ifconfig. Mine is called eth0. It was also called end0.
then:
sudo nano /etc/systemd/system/network-restart.service
insert content:
[Unit] Description=Restart Ethernet interface at boot After=network.target
[Service] Type=oneshot ExecStart=/sbin/ifconfig eth0 down ExecStartPost=/sbin/ifconfig eth0 up RemainAfterExit=true
[Install] WantedBy=multi-user.target
then sudo systemctl enable network-restart.service sudo systemctl start network-restart.service
Hi Radek,
Thank you for your advice.
It seems that it works this way. I wanted to use these commands in this way as well, but unfortunately, I didn’t know how to run them during system boot. When I ran them as "autostart" after the system started, these commands didn't work this way.
I’ll let you know more, probably in about a month, to see if it continues to work like this.
Unfortunately, this solution does not work either. The internet connection is once again sporadic, with the probability of connecting to the internet being approximately 2/10. I also tried a different router, but the issue was not resolved.
OS: Ubuntu noble 24.04 aarch64 Host: Raspberry Pi 5 Model B Rev 1.0 Kernel: Linux 6.8.0-1014-raspi
Thank you Radek Díky Radku : )
The problem seems to be going deeper. For about two months, the RPI booted without a problem. Network unavailable again today. Are you using the RPI itself or some accessories? I have a Pironman 5 with SSD. There might be a problem with the accessory. You can also write to [email protected]. The community doesn't seem interested in investigating the problem in any way, let alone solving it.
Note: Duplicate report here https://github.com/raspberrypi/firmware/issues/1922
I experience the same thing. I do not, though, have any logs for it. I just unplug/re-plug. I develop on Pi2/3/4/5 and have never seen this except on the Pi5. I have never seen it grab a DHCP address, though. When it fails, it has always has a 169.x.x.x address.
Does the Ethernet NIC even blink at all or shows any activity? I don't really understand the fact that you are saying that the DHCP server is able to give you an IP address and also that you are able to ping the pi from another machine but not the other way around... are you sure that you aren't getting an APIPA address?
It would be interesting to know which router / managed switch you are using just to make sure the other side is not the issue, I personally tried on a pi5 with a managed Cisco Switch and an OpenWRT and everything seems to be fine
The network card is active and the LEDs show activity. My RPI receives an IP address (192.168.100.180) from the router. Unfortunately, it is not possible to ping from it to other devices in the network, including the router. But the interesting thing is that RPI can be pinged from devices on the network. My router is built on Banana PI BPI-R3 and Arch linux. Another 6 devices (Smart TV, PC, RPI 4, Orange PI and others) are connected to it via LAN without apparent problems.
The network card is active and the LEDs show activity. My RPI receives an IP address (192.168.100.180) from the router. Unfortunately, it is not possible to ping from it to other devices in the network, including the router. But the interesting thing is that RPI can be pinged from devices on the network. My router is built on Banana PI BPI-R3 and Arch linux. Another 6 devices (Smart TV, PC, RPI 4, Orange PI and others) are connected to it via LAN without apparent problems.
Interesting, are you able to use Wireshark or any other tool when this happens so that we can see if the Pi even sends the packet? It would be useful to know if the packets gets stuck while being sent or the other device responds back but the response gets ignored by the Pi.
@radekjuthner This is happening with the current version of Raspberry Pi OS too right? I want to perform some testings myself but I need to be sure that the latest available version still has this issue.
Yes. I have seen it with the latest PiOS 6.6.y. When I have queried it, I have seen it with an APIPA address. 169.254.x.x
Yes. I have seen it with the latest PiOS 6.6.y. When I have queried it, I have seen it with an APIPA address. 169.254.x.x
This means that DHCP failed tho... I assume your NIC was blinking, I still wonder where the issue is... It seems like there's something that makes packets drop incoming packets to the pi.
@alessandromrc
I keep the system up to date. Unfortunately, the error occurs very sporadically and randomly. It is difficult to confirm its occurrence at the moment.
Well @radekjuthner, when this issue occurs, could you run tcpdump on the Raspberry Pi to check if it’s sending and receiving packets?
To install tcpdump you need to be sudo and run this command:
sudo apt install tcpdump
Then if you just want to log incoming/outgoing packets you can just run
sudo tcpdump
In my case I would like you to run:
sudo tcpdump -w dump
That command will dump every packet that is outgoing and incoming on all the interfaces available on the Pi. (In this case you can just ping another machine like your gateway from your Pi)
I would like to have such dump so that I can analyze what is going on within the networking stack.
It would also be helpful to get an overview of your network interfaces. Please run:
ip a
and send the output here.
I just rebooted my Pi around 50 times and I was unable to replicate this, this is my kernel version:
Linux raspberrypi5 6.6.51+rpt-rpi-2712 #1 SMP PREEMPT Debian 1:6.6.51-1+rpt3 (2024-10-08) aarch64 GNU/Linux
and this is my rpi-issue:
Raspberry Pi reference 2024-11-19
Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, 891df1e21ed2b6099a2e6a13e26c91dea44b34d4, stage5
@alessandromrc An error occurred a while ago. I am attaching the required outputs.
`sudo tcpdump tcpdump: verbose output suppressed, use -v[v]... for full protocol decode listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes 19:29:28.816899 ARP, Request who-has 192.168.100.1 tell 192.168.100.190, length 46 19:29:28.870753 ARP, Request who-has 192.168.100.130 tell 192.168.100.180, length 28 19:29:29.820434 IP 192.168.100.190.8001 > 224.0.0.7.8001: UDP, length 179 19:29:29.878315 ARP, Request who-has 192.168.100.130 tell 192.168.100.180, length 28 19:29:29.895528 IP 192.168.100.190.45626 > 192.168.100.255.15600: UDP, length 35 19:29:30.861395 ARP, Request who-has 192.168.100.1 tell 192.168.100.190, length 46 19:29:30.902316 ARP, Request who-has 192.168.100.130 tell 192.168.100.180, length 28 19:29:31.823247 IP 192.168.100.190.8001 > 224.0.0.7.8001: UDP, length 179 19:29:31.926403 ARP, Request who-has 192.168.100.130 tell 192.168.100.180, length 28 19:29:32.896208 IP 192.168.100.190.45997 > 239.255.255.250.15600: UDP, length 35 19:29:32.904775 ARP, Request who-has 192.168.100.1 tell 192.168.100.190, length 46 19:29:32.950314 ARP, Request who-has 192.168.100.130 tell 192.168.100.180, length 28 19:29:41.142510 ARP, Request who-has 192.168.100.130 tell 192.168.100.180, length 28 19:29:53.430515 ARP, Request who-has 192.168.100.130 tell 192.168.100.180, length 28 19:30:05.718540 ARP, Request who-has 192.168.100.130 tell 192.168.100.180, length 28 19:30:05.788797 IP 192.168.100.190.3955 > 239.255.255.250.1900: UDP, length 307 19:30:05.789690 IP 192.168.100.190.3955 > 239.255.255.250.1900: UDP, length 316 19:30:05.790547 IP 192.168.100.190.3955 > 239.255.255.250.1900: UDP, length 369 19:30:05.791362 IP 192.168.100.190.3955 > 239.255.255.250.1900: UDP, length 365 19:30:05.820786 IP 192.168.100.190.3955 > 239.255.255.250.1900: UDP, length 312 19:30:05.821598 IP 192.168.100.190.3955 > 239.255.255.250.1900: UDP, length 321 19:30:05.822278 IP 192.168.100.190.3955 > 239.255.255.250.1900: UDP, length 374 19:30:05.822882 IP 192.168.100.190.3955 > 239.255.255.250.1900: UDP, length 360 19:30:05.864974 IP 192.168.100.190.3955 > 239.255.255.250.1900: UDP, length 306 19:30:05.865684 IP 192.168.100.190.3955 > 239.255.255.250.1900: UDP, length 315 19:30:05.866320 IP 192.168.100.190.3955 > 239.255.255.250.1900: UDP, length 362 19:30:05.866953 IP 192.168.100.190.3955 > 239.255.255.250.1900: UDP, length 370 19:30:05.867550 IP 192.168.100.190.3955 > 239.255.255.250.1900: UDP, length 372 19:30:05.868137 IP 192.168.100.190.3955 > 239.255.255.250.1900: UDP, length 360 19:30:05.868829 IP 192.168.100.190.3955 > 239.255.255.250.1900: UDP, length 380 19:30:05.873551 IP 192.168.100.190.8001 > 224.0.0.7.8001: UDP, length 179 19:30:05.902903 IP 192.168.100.190.43101 > 192.168.100.255.15600: UDP, length 35 19:30:05.997839 IP 192.168.100.190.3955 > 239.255.255.250.1900: UDP, length 307 19:30:05.998867 IP 192.168.100.190.3955 > 239.255.255.250.1900: UDP, length 316 19:30:05.999784 IP 192.168.100.190.3955 > 239.255.255.250.1900: UDP, length 369 19:30:06.000812 IP 192.168.100.190.3955 > 239.255.255.250.1900: UDP, length 365 19:30:06.028887 IP 192.168.100.190.3955 > 239.255.255.250.1900: UDP, length 312 19:30:06.029584 IP 192.168.100.190.3955 > 239.255.255.250.1900: UDP, length 321 19:30:06.030211 IP 192.168.100.190.3955 > 239.255.255.250.1900: UDP, length 374 19:30:06.030796 IP 192.168.100.190.3955 > 239.255.255.250.1900: UDP, length 360 19:30:06.074841 IP 192.168.100.190.3955 > 239.255.255.250.1900: UDP, length 306 19:30:06.075575 IP 192.168.100.190.3955 > 239.255.255.250.1900: UDP, length 315 19:30:06.076424 IP 192.168.100.190.3955 > 239.255.255.250.1900: UDP, length 362 19:30:06.077249 IP 192.168.100.190.3955 > 239.255.255.250.1900: UDP, length 370 19:30:06.077883 IP 192.168.100.190.3955 > 239.255.255.250.1900: UDP, length 372 19:30:06.078472 IP 192.168.100.190.3955 > 239.255.255.250.1900: UDP, length 360 19:30:06.079047 IP 192.168.100.190.3955 > 239.255.255.250.1900: UDP, length 380 19:30:11.883985 IP 192.168.100.190.8001 > 224.0.0.7.8001: UDP, length 179 19:30:11.904097 IP 192.168.100.190.36031 > 192.168.100.255.15600: UDP, length 35 19:30:13.469929 ARP, Request who-has 192.168.100.1 tell 192.168.100.190, length 46 19:30:13.886569 IP 192.168.100.190.8001 > 224.0.0.7.8001: UDP, length 179 19:30:14.904749 IP 192.168.100.190.52739 > 239.255.255.250.15600: UDP, length 35 19:30:15.489311 ARP, Request who-has 192.168.100.1 tell 192.168.100.190, length 46 19:30:15.889697 IP 192.168.100.190.8001 > 224.0.0.7.8001: UDP, length 179 19:30:17.513538 ARP, Request who-has 192.168.100.1 tell 192.168.100.190, length 46 19:30:17.892769 IP 192.168.100.190.8001 > 224.0.0.7.8001: UDP, length 179 19:30:17.905326 IP 192.168.100.190.57780 > 192.168.100.255.15600: UDP, length 35 19:30:19.541614 ARP, Request who-has 192.168.100.1 tell 192.168.100.190, length 46 19:30:19.895984 IP 192.168.100.190.8001 > 224.0.0.7.8001: UDP, length 179 19:30:20.905945 IP 192.168.100.190.34879 > 239.255.255.250.15600: UDP, length 35 19:30:21.565381 ARP, Request who-has 192.168.100.1 tell 192.168.100.190, length 46 19:30:21.900348 IP 192.168.100.190.8001 > 224.0.0.7.8001: UDP, length 179 19:30:22.405985 f6:ed:fb:39:73:75 (oui Unknown) > Broadcast Null Unnumbered, xid, Flags [Response], length 6: 01 00 19:30:22.489886 IP 0.0.0.0 > 224.0.0.22: igmp v3 report, 1 group record(s) 19:30:22.506557 ARP, Request who-has 192.168.100.130 tell 192.168.100.180, length 28 19:30:22.522809 IP6 :: > ff02::1:ff39:7375: ICMP6, neighbor solicitation, who has fe80::f4ed:fbff:fe39:7375, length 32 19:30:22.526007 IP6 :: > ff02::16: HBH ICMP6, multicast listener report v2, 2 group record(s), length 48 19:30:22.536731 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from f6:ed:fb:39:73:75 (oui Unknown), length 290 19:30:22.537195 ARP, Request who-has 192.168.100.25 tell 192.168.100.1, length 46 19:30:22.895255 IP 0.0.0.0 > 224.0.0.22: igmp v3 report, 1 group record(s) 19:30:23.288372 IP6 fe80::f4ed:fbff:fe39:7375 > ip6-allrouters: ICMP6, router solicitation, length 16 19:30:23.291969 IP6 fe80::f4ed:fbff:fe39:7375 > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 19:30:23.508069 IP6 fe80::f4ed:fbff:fe39:7375 > ff02::16: HBH ICMP6, multicast listener report v2, 2 group record(s), length 48 19:30:23.510313 ARP, Request who-has 192.168.100.130 tell 192.168.100.180, length 28 19:30:23.561658 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from f6:ed:fb:39:73:75 (oui Unknown), length 290 19:30:23.563891 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from f6:ed:fb:39:73:75 (oui Unknown), length 300 19:30:23.585899 ARP, Request who-has 192.168.100.1 tell 192.168.100.190, length 46 19:30:23.595577 ARP, Request who-has 192.168.100.25 tell 192.168.100.1, length 46 19:30:23.607907 IP6 fe80::f4ed:fbff:fe39:7375 > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 19:30:23.730898 ARP, Request who-has 192.168.100.130 tell 192.168.100.25, length 46 19:30:23.733505 IP 192.168.100.25 > 224.0.0.22: igmp v3 report, 1 group record(s) 19:30:23.762195 IP 192.168.100.25.mdns > 224.0.0.251.mdns: 1 [3q] PTR (QU)? _674A0243._sub._googlecast._tcp.local. PTR (QU)? _8E6C866D._sub._googlecast._tcp.local. PTR (QU)? _googlecast._tcp.local. (77) 19:30:34.778473 ARP, Request who-has 192.168.100.130 tell 192.168.100.180, length 28 19:30:45.917042 IP 192.168.100.180.46872 > 192.168.100.130.domain: 32801+ PTR? 251.0.0.224.in-addr.arpa. (42) 19:30:45.917653 ARP, Request who-has 192.168.100.1 tell 192.168.100.190, length 46 19:30:45.934038 IP 192.168.100.190.8001 > 224.0.0.7.8001: UDP, length 179 19:30:47.911423 IP 192.168.100.190.36179 > 192.168.100.255.15600: UDP, length 35 19:30:47.934736 IP 192.168.100.190.8001 > 224.0.0.7.8001: UDP, length 179 19:30:47.953707 ARP, Request who-has 192.168.100.1 tell 192.168.100.190, length 46 19:30:49.263062 IP 192.168.100.25.mdns > 224.0.0.251.mdns: 4 [3q] PTR (QM)? _674A0243._sub._googlecast._tcp.local. PTR (QM)? _8E6C866D._sub._googlecast._tcp.local. PTR (QM)? _googlecast._tcp.local. (77) 19:30:49.937196 IP 192.168.100.190.8001 > 224.0.0.7.8001: UDP, length 179 19:30:49.978599 ARP, Request who-has 192.168.100.1 tell 192.168.100.190, length 46 19:30:50.912016 IP 192.168.100.190.51183 > 239.255.255.250.15600: UDP, length 35 19:30:50.922081 IP 192.168.100.180.46872 > 192.168.100.130.domain: 32801+ PTR? 251.0.0.224.in-addr.arpa. (42) 19:30:55.947767 IP 192.168.100.190.8001 > 224.0.0.7.8001: UDP, length 179 19:30:56.045739 ARP, Request who-has 192.168.100.1 tell 192.168.100.190, length 46 19:30:56.419653 ARP, Request who-has 192.168.100.12 tell 192.168.100.12, length 46 19:30:56.466458 IP 192.168.100.180.58313 > 192.168.100.130.domain: 27116+ PTR? 12.100.168.192.in-addr.arpa. (45) 19:30:56.913267 IP 192.168.100.190.57142 > 239.255.255.250.15600: UDP, length 35 19:30:57.950980 IP 192.168.100.190.8001 > 224.0.0.7.8001: UDP, length 179 19:30:58.066587 IP 192.168.100.120.51843 > 239.255.255.250.1900: UDP, length 170 19:30:58.074099 ARP, Request who-has 192.168.100.1 tell 192.168.100.190, length 46 19:30:58.134473 IP 192.168.100.180.58545 > 192.168.100.130.domain: 18199+ A? 0.debian.pool.ntp.org. (39) 19:30:58.134484 IP 192.168.100.180.58545 > 192.168.100.130.domain: 46610+ AAAA? 0.debian.pool.ntp.org. (39) 19:30:59.074451 IP 192.168.100.120.51843 > 239.255.255.250.1900: UDP, length 170 19:30:59.913881 IP 192.168.100.190.51932 > 192.168.100.255.15600: UDP, length 35 19:30:59.952497 IP 192.168.100.190.8001 > 224.0.0.7.8001: UDP, length 179 19:31:06.476701 IP 192.168.100.180.60810 > 192.168.100.130.domain: 194+ PTR? 120.100.168.192.in-addr.arpa. (46) 19:31:07.966381 IP 192.168.100.190.8001 > 224.0.0.7.8001: UDP, length 179 19:31:08.143609 IP 192.168.100.180.56944 > 192.168.100.130.domain: 59586+ A? 1.debian.pool.ntp.org. (39) 19:31:08.143620 IP 192.168.100.180.56944 > 192.168.100.130.domain: 41464+ AAAA? 1.debian.pool.ntp.org. (39) 19:31:08.225928 ARP, Request who-has 192.168.100.1 tell 192.168.100.190, length 46 19:31:08.915728 IP 192.168.100.190.34870 > 239.255.255.250.15600: UDP, length 35 19:31:17.917611 IP 192.168.100.190.41427 > 192.168.100.255.15600: UDP, length 35 19:31:17.984025 IP 192.168.100.190.8001 > 224.0.0.7.8001: UDP, length 179 19:31:18.150938 IP 192.168.100.180.43841 > 192.168.100.130.domain: 50485+ A? 2.debian.pool.ntp.org. (39) 19:31:18.150949 IP 192.168.100.180.43841 > 192.168.100.130.domain: 57929+ AAAA? 2.debian.pool.ntp.org. (39) 19:31:18.366100 ARP, Request who-has 192.168.100.1 tell 192.168.100.190, length 46 19:31:19.671578 ARP, Request who-has 192.168.100.178 tell 192.168.100.1, length 46 19:31:19.738441 IP 192.168.100.180.52838 > 192.168.100.130.domain: 63646+ PTR? 178.100.168.192.in-addr.arpa. (46) 19:31:19.987494 IP 192.168.100.190.8001 > 224.0.0.7.8001: UDP, length 179 19:31:20.390114 ARP, Request who-has 192.168.100.1 tell 192.168.100.190, length 46 19:31:20.724270 ARP, Request who-has 192.168.100.178 tell 192.168.100.1, length 46 19:31:20.918185 IP 192.168.100.190.47945 > 239.255.255.250.15600: UDP, length 35 19:31:21.764783 ARP, Request who-has 192.168.100.178 tell 192.168.100.1, length 46 19:31:21.990567 IP 192.168.100.190.8001 > 224.0.0.7.8001: UDP, length 179 19:31:29.920134 IP 192.168.100.190.60776 > 192.168.100.255.15600: UDP, length 35 19:31:30.004743 IP 192.168.100.190.8001 > 224.0.0.7.8001: UDP, length 179 19:31:30.094556 IP 192.168.100.66.mdns > 224.0.0.251.mdns: 0 [4q] PTR (QU)? _rdlink._tcp.local. PTR (QU)? _companion-link._tcp.local. PTR (QU)? _hap._tcp.local. PTR (QU)? _hap._udp.local. (85) 19:31:30.094715 IP6 fe80::8ac:58a3:a83b:2bad.mdns > ff02::fb.mdns: 0 [4q] PTR (QU)? _rdlink._tcp.local. PTR (QU)? _companion-link._tcp.local. PTR (QU)? _hap._tcp.local. PTR (QU)? _hap._udp.local. (85) 19:31:30.101920 IP 192.168.100.66 > 224.0.0.2: igmp leave 224.0.0.251 19:31:30.101993 IP 192.168.100.66 > 224.0.0.251: igmp v2 report 224.0.0.251 19:31:30.154427 IP 192.168.100.180.57091 > 192.168.100.130.domain: 53316+ PTR? 66.100.168.192.in-addr.arpa. (45) 19:31:30.262317 ARP, Request who-has 192.168.100.130 tell 192.168.100.180, length 28 19:31:30.530438 ARP, Request who-has 192.168.100.1 tell 192.168.100.190, length 46 19:31:31.098017 IP 192.168.100.66.mdns > 224.0.0.251.mdns: 0 [1a] [4q] PTR (QM)? _rdlink._tcp.local. PTR (QM)? _companion-link._tcp.local. PTR (QM)? _hap._tcp.local. PTR (QM)? _hap._udp.local. (128) 19:31:31.098258 IP6 fe80::8ac:58a3:a83b:2bad.mdns > ff02::fb.mdns: 0 [1a] [4q] PTR (QM)? _rdlink._tcp.local. PTR (QM)? _companion-link._tcp.local. PTR (QM)? _hap._tcp.local. PTR (QM)? _hap._udp.local. (128) 19:31:32.008596 IP 192.168.100.190.8001 > 224.0.0.7.8001: UDP, length 179 19:31:32.554987 ARP, Request who-has 192.168.100.1 tell 192.168.100.190, length 46 19:31:32.920773 IP 192.168.100.190.56498 > 239.255.255.250.15600: UDP, length 35 19:31:54.938436 ARP, Request who-has 192.168.100.1 tell 192.168.100.190, length 46 19:31:56.046984 IP 192.168.100.190.8001 > 224.0.0.7.8001: UDP, length 179 19:31:56.085572 ARP, Request who-has 192.168.100.178 tell 192.168.100.1, length 46 19:31:56.156218 IP 192.168.100.120.mdns > 224.0.0.251.mdns: 0 PTR (QM)? _spotify-connect._tcp.local. (45) 19:31:56.156576 IP6 fe80::218e:b59:73f0:3386.mdns > ff02::fb.mdns: 0 PTR (QM)? _spotify-connect._tcp.local. (45) 19:31:56.190443 ARP, Request who-has 192.168.100.130 tell 192.168.100.180, length 28 19:31:56.420042 ARP, Request who-has 192.168.100.12 tell 192.168.100.12, length 46 19:31:56.698462 IP 192.168.100.120.55987 > 239.255.255.250.1900: UDP, length 125 19:31:56.925698 IP 192.168.100.190.37118 > 239.255.255.250.15600: UDP, length 35 19:31:56.958547 ARP, Request who-has 192.168.100.1 tell 192.168.100.190, length 46 19:31:57.120336 ARP, Request who-has 192.168.100.178 tell 192.168.100.1, length 46 19:31:57.206312 ARP, Request who-has 192.168.100.130 tell 192.168.100.180, length 28 19:31:58.050991 IP 192.168.100.190.8001 > 224.0.0.7.8001: UDP, length 179 19:32:02.326876 ARP, Request who-has 192.168.100.178 tell 192.168.100.1, length 46 19:32:02.927000 IP 192.168.100.190.45568 > 239.255.255.250.15600: UDP, length 35 19:32:03.058842 ARP, Request who-has 192.168.100.1 tell 192.168.100.190, length 46 19:32:03.357111 ARP, Request who-has 192.168.100.178 tell 192.168.100.1, length 46 19:32:04.060431 IP 192.168.100.190.8001 > 224.0.0.7.8001: UDP, length 179 19:32:04.406670 ARP, Request who-has 192.168.100.178 tell 192.168.100.1, length 46 19:32:05.082743 ARP, Request who-has 192.168.100.1 tell 192.168.100.190, length 46 19:32:05.483840 ARP, Request who-has 192.168.100.11 tell 192.168.100.11, length 46 19:32:05.558434 ARP, Request who-has 192.168.100.130 tell 192.168.100.180, length 28 19:32:05.927634 IP 192.168.100.190.35594 > 192.168.100.255.15600: UDP, length 35 19:32:06.063089 IP 192.168.100.190.8001 > 224.0.0.7.8001: UDP, length 179 19:32:06.160773 ARP, Request who-has 192.168.100.178 tell 192.168.100.1, length 46 19:32:06.582319 ARP, Request who-has 192.168.100.130 tell 192.168.100.180, length 28 19:32:07.111598 ARP, Request who-has 192.168.100.1 tell 192.168.100.190, length 46 19:32:07.195703 ARP, Request who-has 192.168.100.178 tell 192.168.100.1, length 46 19:32:11.928899 IP 192.168.100.190.52175 > 192.168.100.255.15600: UDP, length 35 19:32:12.074908 IP 192.168.100.190.8001 > 224.0.0.7.8001: UDP, length 179 19:32:12.402436 ARP, Request who-has 192.168.100.178 tell 192.168.100.1, length 46
sudo tcpdump -w dump tcpdump: listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host noprefixroute valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 2c:cf:67:5a:36:5b brd ff:ff:ff:ff:ff:ff inet 192.168.100.180/24 brd 192.168.100.255 scope global dynamic noprefixroute eth0 valid_lft 42314sec preferred_lft 42314sec 3: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 2c:cf:67:5a:36:5c brd ff:ff:ff:ff:ff:ff
Ping error via GUI:
Ping from routerboard IP 192.168.100. 1to Raspberry Pi5 IP 192.168.100.180:
@radekjuthner,
The frequent ARP requests suggest that the Raspberry Pi is attempting to resolve the Gateway (RouterBOARD) MAC address but isn't able to get a response from other devices in the network.
Have you tried assigning a static IP to the Raspberry Pi to see if that resolves the issue?
Also, it doesn't appear that the DHCP lease has expired, as you can see here:
valid_lft 42314sec preferred_lft 42314sec
The Pi still has around 12 hours left on the lease.
When the issue occurs, could you run the following command in the terminal?
ip neighbour
In any case, assigning a static IP could potentially solve your problem.
@radekjuthner,
Have you tried to assign a static IP to the Pi? Is it any better?
@alessandromrc ip neighbor 192.168.100.136 dev eth0 FAILED 192.168.100.130 dev eth0 INCOMPLETE
@alessandromrc ip neighbor 192.168.100.136 dev eth0 FAILED 192.168.100.130 dev eth0 INCOMPLETE
That seems like you're having some issues with reaching other devices in the network as you're not able to get their MAC address... Are you able to ping those devices from the pi? I suspect that you cannot but maybe the other way around could.
This is a quite weird issue, the only thing I can think of could be a lower-level sided thing within the network NIC management... I am not so sure about how the NIC works on the pi5 as there's the RP1 chip.
Also to be precise, that happens when the pi is unable to reach the Gateway so have you tried assigning a static IP address to the Pi?
Could this be some race condition? I only see it happen at boot. Saw it last night as well. It's as though it doesn't wait long enough for a DHCP response. When it fails to 'connect' or gets an apipa address. When I restart the network manager after it boots (connman or network manager) it will connect.
On Mon, Feb 10, 2025, 07:08 alessandromrc @.***> wrote:
@alessandromrc https://github.com/alessandromrc ip neighbor 192.168.100.136 dev eth0 FAILED 192.168.100.130 dev eth0 INCOMPLETE
That seems like you're having some issues with reaching other devices in the network as you're not able to get their MAC address... Are you able to ping those devices from the pi? I suspect that you cannot but maybe the other way around could.
This is a quite weird issue, the only thing I can think of could be a lower-level sided thing within the network NIC management... I am not so sure about how the NIC works on the pi5 as there's the RP1 chip.
— Reply to this email directly, view it on GitHub https://github.com/raspberrypi/linux/issues/6420#issuecomment-2647938770, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAARWJHPVGMIFA5OUYLU3H32PCQGHAVCNFSM6AAAAABP7PUQJSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNBXHEZTQNZXGA . You are receiving this because you commented.Message ID: @.***>
Could this be some race condition? I only see it happen at boot. Saw it last night as well. It's as though it doesn't wait long enough for a DHCP response. When it fails to 'connect' or gets an apipa address. When I restart the network manager after it boots (connman or network manager) it will connect. …
This is an interesting point of view as I haven't been able to reproduce it, do you have any idea on how to make this reproducible in a manner that is repetable by others?
I wonder if I can code my own DHCP server and "fake" a delay response so that it lands in such weird condition.
Also having a device in the middle between the router and the Pi NIC could be nice as we could sniff packets by using tcpdump / wireshark.
I think the DHCP code in the kernel is here but I am not so sure... the last commit is from 10 Years ago.
I suspect the problem is somewhere in the firmware. The Raspberry Pi 5 has a bootloader that starts before Linux. The bootloader can connect to the network, download the operating system and install it online. It uses DHCP. I noticed the IP address problem in the bootloader before Linux started.