Raspberry Pi 4: Network non-functional directly after (re)boot #3034
Comments
|
Weird, I reboot my Pi4 all the time with no network issues at all, and i have not heard of anyone else with anything similar. Can you try with a different router (or perhaps even reboot your router in case that behaving oddly). |
|
I've tried all that already (check forum thread). All the previous raspberry models work without any issues at the same router. I think it is interesting that the problem can be reset in software. The kernel module should be able to detect this case to "fix" it automatically. |
|
I seem to have similar Problems with my new Pi4. dmesg from tonight: [40987.338593] bcmgenet fd580000.genet eth0: Link is Down |
|
@ummon29 Can you try if "mii-tool -r eth0" fixes the issue for you, too? As the problem only seems to happen for a few Raspberry Pi systems, I think it could be a hardware issue. I still don't think that this is an issue that can't be fixed on kernel side ("mii-tool -r eth0" actually fixes the problem for me) but I'm no kernel hacker. With this specific model it can be reproduced 100% of the time. I would just need more info on how to deliver the info a kernel developer needs. I could also ship the unit to someone with the needed knowledge. I would pay for shipping in one direction but would either want my unit back after some time or the money for the RPi board. |
|
@M-Reimer Not sure yet whether we would need this back - we might. We always replace like for like, plus goodies to pay for the postage. |
|
So I'll wait. My plan was to try to get a refund from the seller in case noone here is interested in this particular unit. |
|
We have noted some strange DHCP issues that seem related to the network hardware, different switches show different results. We'll look in to it. |
|
It doesn't seem to be DHCP issues only. I configured my RPi 4 for static IP and rebooted several times. The journal always says that IP, route and DNS are set properly but it is impossible to reach the RPi. Then I tried the switch thing. I still have some old 100MBit switch and connected it in place of my 1GBit one. With this switch in place I was able to reboot 5 times and network was always available. So yes, this changes with changing the switch. But of course I would prefer to run the 1GBit card on a 1GBit switch 😛 So I think if I buy a second one, then this will show exactly the same problem on this switch? |
|
What make and model is your gigabit switch? Is it managed, and if so what speed, duplex and flow control settings have you set? |
|
D-Link DGS-108 I've ordered a second RPi 4 now. Just to see if a new board causes the same problems on this switch. |
|
At the moment everything is running fine. When it's happening again and I have the opportunity I'll try "mii-tool -r eth0". My Switch is a managed HP 1810-8G The connection is running at 1000Mbps FullDuplex. The error counters are at 0 and the only log entry was that the port was down. Disconnecting an reconnecting didn't work even after a reboot of the RPi. Connecting the RPi with another cable to an AVM FritzBox (7490) worked instantly. After I restarted the Switch everything was fine again. I sill have to replace the cable to rule out that the problem is in the cable. My RPi has a manually configured IP. |
|
It's likely that there is a bug in Ethernet/PHY driver. Even hardware and drivers that appear to work well suddenly develop issues when exposed to the vast number of devices and use cases that make up the world of Pi. We had a very busy few weeks after the launch of the 3B+ with network glitches, but they were sorted eventually. |
|
After changing to another cable and switch still the same problem. dmesg: I had no chance to test "mii-tool -r eth0" yet. |
|
I've received another RPi 4 board, now. I just moved the same SD card to the new board and rebootet about 10 times. With static IP and with DHCP. Never had a problem. But I'll do some more tries just to be sure. I'll then also start to use this board for some 24/7 network stuff to see how stable the ethernet card will be. After this test, I move the SD card back to the old board. First boot activated the network interface without issues but the first "sudo reboot" started in non-functional network, again. Unplugging and replugging the network cable fixed the problem just as before. So this may have something to do with my hardware. Probably in combination with the specific switch that I use. Tell me if it is possible to help with fixing this issue somehow. |
|
Can you try forcing the mac address of the not-working Pi to that of the working Pi? Use the config.txt option |
|
I've tried that (and verified that the mac address really changed). |
|
I have exactly the same issue on my RPi 4 4GB and only unplug and replug the network cable brings the pi back to be able to SSH into it. |
|
I have also experienced this issue and I raised the issue on the Raspberry Pi forum. I now have two Pi 4's each with 4Gb of RAM. With everything the same except the Pi board one works and one does not. As @M-Reimer discovered the only ways to get an IP address with the not working one seem to be to unplug/plug the network cable or to somehow run Let me know if there are any tests or commands you would like me to run. |
|
Any further news or should I just throw away this defective Pi 4? I do not feel it is up to the usual Pi standard in manufacture (I own/have owned more than 10 and this is only the second I have had problems with) and would not feel confident using it in a production environment due to the hack required to make it boot. I wish there was some other way of contacting Raspberry Pi rather than having to air my grievances in public. |
|
@api4user Yes, we would like that device back for internal testing please. We will replace it by return + goodies to cover postage costs. Please contact me via email info@raspberrypi.org, using FAO James Hughes at the top, to arrange how to get it to us. Thanks. |
|
Same for my case or should I return to my seller for a refund? |
|
@M-Reimer Yes please, can you follow instructions in my previous post and contact me via email please. We are trying to get together a database of unusual failures for quality control purposes, so everything is helpful! |
|
I found a bit of time to debug the problem further. [ 159.832782] bcmgenet fd580000.genet eth0: Link is Down I tested with a fresh raspbian buster install to ensure that it's no problem with my old updated system. The problem is the same. |
I guess this "info@" address gets too much mail and so it takes long for the queue to be processed? |
|
A quick Update. |
|
Sorry for the ping I have resolved the issue. It seems that a program edited the dhcpcd.conf to add a static ip. The config was: |
|
I returned my Pi 4 to you a week ago. You emailed to say you could not replicate the problem and were sending my Pi back. I have still not received it back. I am not happy. There definitely IS a problem as one of my Pi's works and the other did not. |
|
@api4user It's only been a week! Please take into account the time to pack stuff up and get it back to you. I wasn't dealing with this one, so will try and find out what is happening. Who emailed you the results? (Difficult to cross reference api4user against an email address/actual identity) |
|
Hi @pelwell ! this is the output : PING 192.168.200.200 (192.168.200.200) from 192.168.200.244 eth0: 56(84) bytes of data. root@RPI-11:~# ifconfig eth0 dmesg is empty |
|
Thanks, but those statistics don't make a lot of sense - it's like the ping packets just disappeared. Have you tried adding |
|
I add genet.skip_umac_reset=n in cmdline.txt, but I have the same issue :( |
|
So, I have run into the same issue. I was able to remedy the issue by typing in "ifconfig eth0 up//sudo dhclient" upon every reboot. However, I was able to "solve" the issue by factory resetting my Raspberry Pi 4 and then installing NOOB and downloading Raspbian (Rasbperry Pi OS) from there. After the reinstall and updating and upgrading the OS, I was able to reboot it with no issue and could connect to the network just fine. I am not sure this will work for everyone though. |
|
so, I have run into the same issue. I am able to get a DHCP address when I set the speed to 100mbps full-duplex or 10mbps (in case of several pi boards), but with the default gigabit ethernet (1gbps) there is no address and it is specific to a D-link switch, the Cisco switch actually allocates an IP to this pi on the gigabit ethernet. I'll share some logs also if it helps. Any help would be appreciated. at least an explanation of what might be happening would help a lot, or any workarounds for the same. Thank you. |
|
I'm having this same problem on 2 RPi4 that I'm using as Pi-Holes. I have tried new cables, new power supplies, new switch and even tried a USB NIC. Nothing solved the problem permanently. Please advise! |
|
same problem here... ip addr shows everything is fine. pings not possible, route -n is empty |
|
So, I don't know if this is a cause or just a symptom, but I noticed in my syslog that other hosts on my network are trying to claim the RPi static addresses. These events seem to occur near the network drops, but the network does NOT drop every time they occur. I've also sniffed my network, and don't see any signs of a rogue DHCP server that would be trying to hand out these addresses. Their static addresses are NOT in my DHCP address range, so I have no idea how or why these hosts are trying to grab the address. Here is a log sample:
|
|
I noticed this weird activity started last week. I use pi4 2gb with latest updates, latest stable firmware and added today the latest eeprom. as most said above, since im next to Pi, if i unplug the cable and put back in, a new correct lan ip received. It seems to me that the dhcp service is messed OR the LAN interface on Pi4 stays alive during reboot rather fully restart as if is when pi4 is powered off. (possible hw pan problem as stated above - even though all was working fine for 9+ months) |
|
My culprit was the office lan cable. |
|
Thanks for reporting back. |
|
I changed cables and the switch the pis were connected to. I ended up replacing them with pi-zeros, and have had NO problems since the replacement. |
|
Bad LAN Cables?! Really? First time in my life heard of that... i dont believe in the LAN Cable theory. By the way i am using CAT-8 and today my blitz refused with "Wait for LAN". Even after reconnect the cable it does not receive a new IP. it needs a Using 1.6.1 here I added a shell script to check network and will try to repair: make it executable with this one could be placed in /root and set in roots crontab with Here i added an additional restart ssh service after each reboot. Tell me your thoughts on this. |
ok it came back with the new cable too. first was random days. now its all day after reboot. its really weird @ChuckNorrison havent tried above but id prefer an official fix rather a good workaround. OS should work as expected :-) |
|
This seems related to disk corruption from power consumption issues on the pi 4. Do not use external hdd on USB 3.0. My script will make it possible to get around the missing ssh login and some failures related to a "bad boot" |
|
As long as i was getting an ip no prob with ssh or corruption but im happy for the script to force the dhcp client to do tis job :-) |
|
I had something similar on a ring network of raspberry pis. Not only when rebooting, but also when reconnecting one of the cables. We tried with 3 usb to eth adapters. 2 of them failed. The one that worked came from the same brand to one that failed:
|
|
I have just updated my Pi3B to the latest OS, and the eth0 will not work...it worked on the previous version of the OS, but seems to be misconfigured, as the port worked earlier. I tried the mii ... command but it didn't reconnect |
|
Well this has been an entertaining thread – how's the lawsuit going 😂 At any rate, here's my 2 cents. I have a (Canokit) 4 Model B Rev1.2 that I purchased Summer 2020, and a 3B Rev 1.2 (from maybe 2 years ago? no memory of where I got it). At the end of the summer I installed 08-20-buster in the "standard" way, and both RPis came up perfectly on both wireless and ethernet. I then let them languish for a while and noted that at some point the 3B dropped off the network. So I went back to it 2 days ago and first discovered that the 3B's microSD card had gone bad. So I redid 08-20-buster on a new flash card and the 3B came right up on wireless as before, but NOT on ethernet – no matter what I did (sorry not listing everything), it always self-assigned a non-routable 169 address. I did also try sudo mii-tool -r eth0 and that did NOT work. However, what DID work was to create a static address in /etc/dhcpcd.conf. That surprised me a bit, but there you go. My observations:
Like voter fraud, I have no real evidence, but my experience suggests to me some subtle interaction with the particular router in question and perhaps the RPi hardware, but my 4 has been rock solid through all of this, and the 3B is pretty old (and presumably not flawed) at this point. Good luck finding this issue, if you are still looking for it, but I think next time, although the static address is simple enough, it obviously doesn't work for everyone and may be less than ideal. I would try a different router if I had to troubleshoot this again. In a month I'm teaching a class in which 35 students are going to have to go through this, and I'm sure they will almost all have 4s because they believe the latest is always the greatest. I've bookmarked this thread and will report back what happens. |
|
Thanks for your comments, here... this issue is quite a bit more
'substantial' than voter fraud, it seems to be more repeatable ... anyway,
I'll try sticking another router in between my cable modem and th 3B, or,
maybe (less desirable), roll back the OS...
Have a ice, and healthy, 'holiday season', or as some say "Merry Christmas"
…On Fri, 25 Dec 2020 at 01:16, rapierbit ***@***.***> wrote:
Well this has been an entertaining thread – how's the lawsuit going 😂
At any rate, here's my 2 cents. I have a (Canokit) 4 Model B Rev1.2 that I
purchased Summer 2020, and a 3B Rev 1.2 (from maybe 2 years ago? no memory
of where I got it). At the end of the summer I installed 08-20-buster in
the "standard" way, and both RPis came up perfectly on both wireless and
ethernet. I then let them languish for a while and noted that at some point
the 3B dropped off the network. So I went back to it 2 days ago and first
discovered that the 3B's microSD card had gone bad. So I redid 08-20-buster
on a new flash card and the 3B came right up on wireless as before, but NOT
on ethernet – no matter what I did (sorry not listing everything), it
always self-assigned a non-routable 169 address. I did also try *sudo
mii-tool -r eth0* and that did NOT work.
However, what DID work was to create a static address in /etc/dhcpcd.conf.
That surprised me a bit, but there you go. My observations:
1. This 3B board ethernet used to work and then didn't, and it had
nothing to do with the OS version.
2. I sadly don't remember what router I used back in the summer, but
for this go-round, I'm using an ancient WRT54G v5 (with the original
Linksys firmware! not even DD_WRT yet).
3. I tried playing with the ethernet cable and also power before I got
it to work, to no avail.
Like voter fraud, I have no real evidence, but my experience suggests to
me some subtle interaction with the particular router in question and
*perhaps* the RPi hardware, but my 4 has been rock solid through all of
this, and the 3B is pretty old (and presumably not flawed) at this point.
Good luck finding this issue, if you are still looking for it, but I think
next time, although the static address is simple enough, it obviously
doesn't work for everyone and may be less than ideal. I would try a
different router if I had to troubleshoot this again.
In a month I'm teaching a class in which 35 students are going to have to
go through this, and I'm sure they will almost all have 4s because they
believe the latest is always the greatest. I've bookmarked this thread and
will report back what happens.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#3034 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AGBMPKSYSVHQ7S5R64ZRYL3SWPKU7ANCNFSM4H4MGJGQ>
.
|
|
I am not sure if my issue is exactly the same, but reading through the posts it seems to be, at the very least, quite similar. I've recently moved my family into a new home. With this comes using a new isp with a new isp-provided router required to use their signal. The provider is Virgin using what they call their superhub 3.0 router. My pi4 has never failed to connect to a wired connection before. I've used it on at least three different routers before I moved without issue. When I hook it up to this router it always reports "no carrier" and no lights come on the lan ports at the back of the router as they do when plugging in any other device. I have tried plugging directly into the router rather than the ethernet ports I have installed in each of the rooms, but still get "no carrier." All other devices -- other Pis and Linux desktop machines, work flawlessly regardless of where they are plugged in, remotely or directly into the router. I have tried using every different available Linux distribution for the pi4, none of which will give me a wired connection or report a carrier present when plugging in. I have then tried disabling default network managers and one by one trying every different piece of software I can find to manage the connection to see if one might know something the others don't and hopefully get it to work. At this point I felt that perhaps the controller had been physically damaged. Why else would every other device work but not this one, even when trying fresh installs of multiple different distributions? But then I tried something that destroyed that theory. I plugged an old netgear router into the new router. I then plugged the pi4 into the netgear router. It Instantly connected with full lan and internet functionality over ethernet. This works if I plug the old router directly into the new router, or if I plug the old router into an ethernet port in another room and then plug the pi4 into it. I am completely bemused, have been trying to figure out what the heck is going on and why, and to make it work without an old router between them for days. I am obsessed and can't seem to let go of it. While it is an effecitve workaround, I don't want to have an extra router between my pi and the router everything else connects to without issue. I've browsed the internet to eyes-are-bloodshot stage and nothing, other than this topic, seems to sound anything like what I'm experiencing. Neither rebooting or replugging the cable nor using a mii-tool command has any effect. If someone were able to provide a solution, or, at the very least, explain why what is happening is happening, it would improve my sleep. I am scratching my head and at a complete loss. |
|
Please create a new Issue for this. |
|
Sorry I can't help, but your problem is exactly like mine, but a Pi 3B,
stopped connecting as soon as I installed newer software, a year newer...
Hope someone can help!!
…On Friday, 1 January 2021, Phil Elwell ***@***.***> wrote:
Please create a new Issue for this.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#3034 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AGBMPKXPM3ZMBT3BZD6XCXTSXWTM3ANCNFSM4H4MGJGQ>
.
|
|
Commenting on the end of a Closed (or just different) issue is a great way to be ignored or forgotten. |
|
After the initial trouble which was the reason for getting this issue closed I was asked to create a new issue which is this (still open) one: #3108 But to this day I still get notifications about this closed issue. Could someone lock conversations here so all discussions happen on the new issue? |
and others
Describe the bug
If I boot directly to an up-to-date Raspbian, then the network starts up in some kind of "no-functional" state. Means that dhcpcd does not manage to get an IP and trying to manually run dhcpcd on the interface hangs forever.
The problem resets if I unplug and replug the network cable. This triggers fetching a valid IP and properly enables the network interface.
It is also possible to reset from the non-functional state by running
sudo mii-tool -r eth0
This also "unblocks" the network card and makes dhcpcd get a new IP.
To reproduce
Seems like not everyone is able to reproduce this bug. Maybe it's even some kind of "hardware problem".
But on affected Raspberry Pi 4 board, everything you have to do is to reboot. Result will be non-functional network.
Expected behaviour
Network should come up without problems every time.
Actual behaviour
Network hangs until mii-tool -r is called or the network cable is unplugged and replugged.
Logs
I already published some logs here:
https://www.raspberrypi.org/forums/viewtopic.php?f=66&t=244061#p1488426
I can provide more if needed.
The text was updated successfully, but these errors were encountered: