triplus
Posts: 31
Joined: Thu Nov 21, 2013 9:03 pm
Location: Belgium, Vilvoorde
Contact: Website Facebook Twitter YouTube

Every thursday I get "dhcpcd[702]: eth0: carrier lost" and network is no longer working

Thu Mar 14, 2019 7:30 am

Hi all

I'm back with a little bit of an issue. Since I installed "motion" on my raspberry pi I keep getting the following in my syslog once a week (3 weeks in a row it has been Thursday). The raspberry itself has been running pi-hole and homeassistant for close to 3 years now without problems.

Code: Select all

[email protected]:~ $ cat /var/log/syslog | grep "carrier lost"
Mar 14 07:17:04 raspberrypi dhcpcd[388]: wlan0: carrier lost
Mar 14 07:17:05 raspberrypi dhcpcd[388]: eth0: carrier lost
[email protected]:~ $ cat /var/log/syslog.1 | grep "carrier lost"
Mar 14 00:42:27 raspberrypi dhcpcd[702]: eth0: carrier lost
[email protected]:~ $
It doesn't happen before Thursday and it doesn't happen after Thursday, until we are on the next Thursday again.
I can also see that at 12:38AM all my sensors stopped sending data to my HomeAssistant, and the error occurs about 4 minutes later so...

I've done some reading already and the closest I can find is power management. I have added

Code: Select all

#https://www.raspberrypi.org/forums/viewtopic.php?t=210059
dtparam=eee=off
to my /boot/config.txt already but this week I got the same error once again...

I have a feeling it may be the usb camera & motion that are causing the issue, but why are those having impact on the wired network. they shouldn't be linked apart from the bus they are sharing, right?

EDIT: Adding the info on my pi:

Code: Select all

[email protected]:~ $ cat /etc/debian_version
9.3
[email protected]:~ $ cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 9 (stretch)"
NAME="Raspbian GNU/Linux"
VERSION_ID="9"
VERSION="9 (stretch)"
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"
[email protected]:~ $ uname -a
Linux raspberrypi 4.9.59-v7+ #1047 SMP Sun Oct 29 12:19:23 GMT 2017 armv7l GNU/Linux
[email protected]:~ $ cat /proc/cpuinfo
processor       : 0
model name      : ARMv7 Processor rev 4 (v7l)
BogoMIPS        : 38.40
Features        : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x0
CPU part        : 0xd03
CPU revision    : 4

processor       : 1
model name      : ARMv7 Processor rev 4 (v7l)
BogoMIPS        : 38.40
Features        : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x0
CPU part        : 0xd03
CPU revision    : 4

processor       : 2
model name      : ARMv7 Processor rev 4 (v7l)
BogoMIPS        : 38.40
Features        : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x0
CPU part        : 0xd03
CPU revision    : 4

processor       : 3
model name      : ARMv7 Processor rev 4 (v7l)
BogoMIPS        : 38.40
Features        : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x0
CPU part        : 0xd03
CPU revision    : 4

Hardware        : BCM2835
Revision        : a02082
Serial          : 000000009e20e0b8
Thanks for helping me crack this one, I don't know how to proceed here...

Kind regards
Joren
- Raspberry Pi Model B since 2013.
- Raspberry Pi Zero since October 2016
- Raspberry Pi 3 since: December 2016

User avatar
B.Goode
Posts: 8917
Joined: Mon Sep 01, 2014 4:03 pm
Location: UK

Re: Every thursday I get "dhcpcd[702]: eth0: carrier lost" and network is no longer working

Thu Mar 14, 2019 9:10 am

Thanks for helping me crack this one, I don't know how to proceed here...


Just basic troubleshooting... ?

If you suspect that adding motion has made the system unstable, what happens if you uninstall or disable that most recent change?

(Or can you set up an otherwise identical test system that does not run motion?)


Or maybe it is a scheduled event on your mains power infrastructure, or network infrastructure, that you never previously noticed because you were not relying on continuous data collection? Again, a second test system connected to the same power and network infrastructure could be used to prove/detect/report that loss of service.

Return to “Troubleshooting”