1

Network setup:

  • A Fritz!Box 7530 AX router with IP 192.168.1.1
  • A Netgear AP WAC104 access point with IP 192.168.1.2, which is connected with ethernet to the router.
  • A Raspberry Pi 4 connected with ethernet to the access point. (192.168.1.39)
  • A laptop connected with ethernet to the access point. (192.168.1.3)

All three devices have their static IP defined in the router.

On the Raspberry Pi, I have the following services:

  • Jellyfin media server
  • Deluge torrent server
  • Pihole running in Docker (DHCP disabled)
  • Snowflake proxy running in Docker
  • DuckDNS cronjob updating my DuckDNS domain every 5 minutes

Output of docker ps:

CONTAINER ID   IMAGE                                  COMMAND        CREATED        STATUS                PORTS                                                                                                                                                        NAMES
9163a3e70584   pihole/pihole:latest                   "/s6-init"     2 weeks ago    Up 2 days (healthy)   0.0.0.0:53->53/udp, :::53->53/udp, 0.0.0.0:53->53/tcp, :::53->53/tcp, 0.0.0.0:8001->8001/tcp, 0.0.0.0:67->67/udp, :::8001->8001/tcp, :::67->67/udp, 80/tcp   pihole
f1ad77eb8b50   thetorproject/snowflake-proxy:latest   "/bin/proxy"   9 months ago   Up 2 days                                                                                                                                                                          snowflake-proxy

Disabling all docker processes did not fix the issue.

The problem

About once a day, the Raspberry Pi seems to break the access point it is connected to. This results in all devices connected to the access point to stop getting an IP. I connect my laptop to the router's WiFi, and notice that pinging the access point doesn't work: "Destination Host Unreachable".

The problem is fixed when I disconnect the power to my Pi. Pinging to the AP immediately works again when I do that. Repowering the Pi again will work fine until the next time it happens.

I used to have this exact problem every day when I was using home-assistant on my Pi (through Docker). Stopping the home assistant container fixed that problem. But two days ago I updated my Pi from bullseye to the bookworm repositories (because I was annoyed the bullseye packages were so outdated and wanted to test out bookworm) and since then the same problem has returned.

If I look in the logs, I notice the Pi seems to have stopped logging at 06:25: https://pastebin.com/yaF6h8tD. I unplugged the power at 11:20, plugged it back in at 11:21.

These are the last couple of lines before it stopped logging anything:

2023-07-19T06:25:22.138841+02:00 raspberrypi (udev-worker)[2418]: regulatory.0: Process '/lib/crda/crda' failed with exit code 254.
2023-07-19T06:25:24.308720+02:00 raspberrypi systemd[1]: systemd-fsckd.service: Deactivated successfully.
2023-07-19T06:25:25.319725+02:00 raspberrypi dhcpcd[454]: veth7e8dbc6: using IPv4LL address 169.254.174.162
2023-07-19T06:25:25.320258+02:00 raspberrypi dhcpcd[454]: veth7e8dbc6: adding route to 169.254.0.0/16
2023-07-19T06:25:25.321719+02:00 raspberrypi avahi-daemon[401]: Joining mDNS multicast group on interface veth7e8dbc6.IPv4 with address 169.254.174.162.
2023-07-19T06:25:25.322238+02:00 raspberrypi avahi-daemon[401]: New relevant interface veth7e8dbc6.IPv4 for mDNS.
2023-07-19T06:25:25.323011+02:00 raspberrypi avahi-daemon[401]: Registering new address record for 169.254.174.162 on veth7e8dbc6.IPv4.
2023-07-19T06:25:25.455712+02:00 raspberrypi (udev-worker)[2441]: regulatory.0: Process '/lib/crda/crda' failed with exit code 254.
  • Rebooting the Pi (by unplugging & replugging the power) fixes the problem.
  • Removing the ethernet cable from the Pi fixes the access point immediately. All devices connected to the router then work fine, except for the Pi itself.
  • Plugging the ethernet cable back in without rebooting the Pi makes the problem reappear after a few seconds.
  • The ethernet port's lights are still flashing when the problem occurs.
  • Attaching a serial cable to the Pi doesn't open a terminal if I try to connect while the the problem is present.
  • The Pi's green ACT LED is either continously on, or not on at all.
  • Trying to open a link-local connection to the Pi from my laptop doesn't work when the problem is present, but I can ping the link-local IP.
  • I have removed the avahi-daemon package as requested in the comments, but the problem still occurs.
  • I have removed the crda package as I read this isn't necessary anymore (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003903)

I bought a TTL to USB serial cable to try to fix this, by connecting the cable to my laptop to see if I can get a serial console to the Pi when the problem occurs.

I tried that yesterday and today (2023-08-13) when the problem occured and both times it doesn't even open a terminal connection. Rebooting the Pi fixes it again, and I can confirm the serial connection does work properly if the Pi is running normally. If a serial connection doesn't even work, I guess this means the problem causes the entire RPi to stop working somehow?

What could be the cause of this issue? Is there anything else I can provide (config files, logs)?

Q&A:

The issue sounds predictable. Would it be possible for you to plug in a monitor and watch it while it happens

Watching a monitor while it happens is a bit difficult because it only happens a maximum of once a day (sometimes with multiple days of no issues in between), and I don't really have a spare monitor I can hook up for multiple days. I haven't been able to hook up a monitor while the Pi is already running, as it doesn't seem to accept the input video mode (see above).

Maybe your running a DHCP server of some kind on your PI and its handing out IP and causing confusion. service isc-dhcp-server status However, there are other light weight dhcp servers that exist. Maybe use "service --status-all". Your existing devices would maintain there existing IP until their IP lease time expired as soon as this happens it could grab an IP from your PI

$ service isc-dhcp-server status
Unit isc-dhcp-server.service could not be found.

I am running Pi-hole but the DHCP feature is disabled. Here's the full output of sudo service --status-all: https://pastebin.com/raw/yZFigg6h

Updates

  • Happened on 2023-07-20: https://pastebin.com/Z0ZRQfuQ
  • Happened on 2023-07-24, at 15:36, while I was working on my laptop. My connection suddenly dropped and I . Here is the output of journalctl --since 15:00: https://pastebin.com/ZrdKzWj6. I rebooted at around 16:20.
  • Happened again on 2023-07-25 at 19:10. I didn't see anything new in the logs other than what is already in the logs posted above.
  • Happened again on 2023-07-28 at around 21:50. This time, the green ACT LED of the Pi was not on, not even flashing.
  • 2023-07-29: I stopped and disabled the avahi-daemon.service and avahi-daemon.socket using systemctl stop and systemctl disable. The problem happened again today (2023-08-01).
  • The problem occured again (2023-08-02).
  • I now moved to a new house (2023-09-18) with a different modem (my provider's proprietary modem). I still use the same router. The problem still occurs.
    • Yesterday (2023-10-14) the Pi's green ACT LED was suddenly on continuously, the Pi responded to pings but I could not connect to it (not through ssh nor through serial to usb connection). The router still functioned fine.
    • Today (2023-10-15), the Pi's green ACT led was off, and the router and Pi both stopped working. Pinging to the router or Pi was not possible.

What's interesting: the issue did not occur between when I moved and yesterday. Earlier this week, I set up my DynDNS settings on my modem (DuckDNS on my Pi was already set up, but I hadn't set up the correct settings on my modem yet). That's the only thing I can think of that has changed recently.

Improve this question
14
  • 1
    "If I look at the full log, it looks as if it rebooted at 06:22, but I don't understand why" -> Because the Pi does not have an RTC (realtime clock). Hence, it has no way of knowing what the real time is until it connects to a time server. Before that, it uses a timestamp from sometime before it shutdown (ie., this is totally normal).
    – goldilocks ♦
    Commented Jul 24, 2023 at 15:19
  • 1
    It's very hard to see what a Pi could do to cause this problem unless it has been malwared or there is some hardware malfunction involved (ie., it's an electrical problem). I presume the AP is a black box -- does the router have logs you can access? Have you tried plugging the Pi into the router instead? It may actually be a symptom of something vs. the cause, if it behaves normally in another setting.
    – goldilocks ♦
    Commented Jul 24, 2023 at 16:16
  • 1
    Also, the issue sounds predictable. Would it be possible for you to plug in a monitor and watch it while it happens?
    – goldilocks ♦
    Commented Jul 24, 2023 at 16:18
  • 1
    And: If the laptop is on the same AP, leave wireshark running on it. You don't have to be watching w/ that since it keeps a record you can view latter. If it turns out nothing unusual is happening when it bogs up, that points to an electrical problem. Otherwise there should be some incredible flurry of traffic a la a DoS attack (real, or some bit of software gone haywire), unless some malware on the pi is hacking the AP in a more subtle way (but there will solid clues to that as well).
    – goldilocks ♦
    Commented Jul 24, 2023 at 16:24
  • 1
    The point about the ethernet and ACT leds is pretty significant; really you should refer to that at the top of the question as it is strongly implies the OS is working (which is otherwise dubious). I don't think running tshark on the Pi will be very effective as something else potentially running up the processor and accessing the SD card may hamstring it.
    – goldilocks ♦
    Commented Jul 24, 2023 at 19:09

3 Answers 3

Reset to default
1

TL;DR: Reinstalling Bookworm Raspbian from image gets around this issue.

Ran into the exact same issue as OP. Upgraded Raspbian in-place from Bullseye to Bookworm via the apt method that should work for all Debian systems.

Was running into daily system crashes, unknown reason. Same Process '/lib/crda/crda' error in syslog. None of the above solutions worked. What did work was backing up customized files, re-installing Raspbian OS Bookworm from an image, and re-provisioning the system using the backups. I don't think I'll trust non-manual updates on Raspbian for a while, and Raspbian in-place upgrades for a long while.

Improve this answer
1
  • 1
    I completely reinstalled Bookworm as well about a month ago, and can confirm the issue has stopped occuring since then (I wanted to wait a while to update the thread, just to be sure). Great to hear I'm not alone in this, thanks for sharing your experience.
    – zjeffer
    Commented Nov 17, 2023 at 16:26
1
+100

Try to disable and eventually disinstall Avahi Daemon.

Avahi is a free, open-source implementation of the Zeroconf networking protocol. It allows devices such as computers, printers, IP phones, and other networked devices to automatically discover each other without the need for manual configuration. Avahi is most commonly used on Linux systems, and is implemented as a daemon process called avahi-daemon. This daemon is responsible for listening for network traffic related to Zeroconf services, and responding to requests for information about those services.

Reading your log at the time of the connection issue:

2023-07-20T06:26:01.412948+02:00 raspberrypi avahi-daemon[414]: Joining mDNS multicast group on interface eth0.IPv4 with address 192.168.1.39.
2023-07-20T06:26:01.414001+02:00 raspberrypi avahi-daemon[414]: New relevant interface eth0.IPv4 for mDNS.
2023-07-20T06:26:01.414699+02:00 raspberrypi avahi-daemon[414]: Registering new address record for 192.168.1.39 on eth0.IPv4.

where you can find the avahi-daemon.

First note Avahi PID using:

top

You will find these info: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

Then kill the task using:

sudo kill <PID number>

The "avahi-daemon" service can be disabled with the following commands:

sudo systemctl disable avahi-daemon.service
chkconfig avahi-daemon off
service avahi-daemon stop

and can be disinstalled with the following:

sudo apt-get remove avahi-daemon
sudo apt autoremove

Moreover, since the Avahi daemon service keeps an open network port, it is subject to network attacks. I would suggest to note if using 'top' any other users are shown excluding yourself and root, that is not always a drama, but it is better to investigate in that case.

Please find more details here:

https://wiki.debian.org/Avahi

and here:

https://www.stigviewer.com/stig/red_hat_enterprise_linux_6/2020-09-03/finding/V-218006

Improve this answer
12
  • Thanks! I disabled and stopped the avahi-daemon.service and -.socket using systemctl because I don't have the chkconfig command. I assume it will have the same effect? I'll see if the problem persists in the next couple of days.
    – zjeffer
    Commented Jul 29, 2023 at 9:54
  • 1
    That's great, you are welcome !
    – Luca Spuntoni
    Commented Jul 29, 2023 at 10:03
  • 1
    That is right the command to disable it is: sudo systemctl disable avahi-daemon.service I have edited the answer as well.
    – Luca Spuntoni
    Commented Jul 29, 2023 at 10:09
  • Sadly it happened again today. I'll update the post. It looks like the avahi daemon is running again...
    – zjeffer
    Commented Aug 1, 2023 at 17:09
  • Also I just noticed when looking through the avahi daemon logs that the number between the square brackets is not an error code, but that seems to be the process ID. So the avahi-daemon messages might not even be errrors. Can you update your answer with this?
    – zjeffer
    Commented Aug 1, 2023 at 17:33
1

Executing sudo update-alternatives --config regulatory.db and selecting /lib/firmware/regulatory.db-upstream (option 2) solved the problem for me as explained here.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.