2

I have Ubuntu 22.04 LTS (GNU/Linux 5.15.0-1008-raspi armv7l) running on a raspberry Pi 3.

For some reason, after around 2 days of uptime, it starts randomly removing its global IPv6 address. The IPv6 address comes back once the computer receives an ICMP RA packet.

Rebooting the system gives another 2 days without incidents.

This was also happening on a freshly installed system.

Our router advertises a router lifetime of 1800 seconds, and a prefix lifetime of 3600 seconds. Tcpdump says our router sends a ICMP RA every 600 seconds. Even when using watch to watch the output of ip addr, there are 4 digit numbers left on the countdown when the addres gets removed. (It just happened that the IPv6 address was lost within 2 seconds of receiving the RA)

When the system is working, ip addr looks like

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 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether zz:zz:zz:zz:zz:zz brd ff:ff:ff:ff:ff:ff
    inet 192.168.178.53/24 metric 100 brd 192.168.178.255 scope global dynamic eth0
       valid_lft 624462sec preferred_lft 624462sec
    inet6 yyyy:yyyy:yyyy:yyyy:xxxx:xxxx:xxxx:xxxx/64 scope global dynamic mngtmpaddr noprefixroute 
       valid_lft 7197sec preferred_lft 3597sec
    inet6 fe80::xxxx:xxxx:xxxx:xxxx/64 scope link 
       valid_lft forever preferred_lft forever
3: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether b8:27:eb:a3:c0:93 brd ff:ff:ff:ff:ff:ff
4: teredo: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1280 qdisc fq_codel state UNKNOWN group default qlen 500
    link/none 
    inet6 2001:0:zzzz:zzzz:zzzz:zzzz/32 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::ffff:ffff:ffff/64 scope link 
       valid_lft forever preferred_lft forever
    inet6 fe80::9a37:a9a:298d:ac5c/64 scope link stable-privacy 
       valid_lft forever preferred_lft forever

When it is broken, the system looks like

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 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether zz:zz:zz:zz:zz:zz brd ff:ff:ff:ff:ff:ff
    inet 192.168.178.53/24 metric 100 brd 192.168.178.255 scope global dynamic eth0
       valid_lft 622714sec preferred_lft 622714sec
    inet6 fe80::xxxx:xxxx:xxxx:xxxx/64 scope link 
       valid_lft forever preferred_lft forever
3: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether b8:27:eb:a3:c0:93 brd ff:ff:ff:ff:ff:ff
4: teredo: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1280 qdisc fq_codel state UNKNOWN group default qlen 500
    link/none 
    inet6 2001:0:zzzz:zzzz:zzzz:zzzz/32 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::ffff:ffff:ffff/64 scope link 
       valid_lft forever preferred_lft forever
    inet6 fe80::9a37:a9a:298d:ac5c/64 scope link stable-privacy 
       valid_lft forever preferred_lft forever

The syslog does not give any clues to this issue (only symptoms): [full file]

Jun  7 17:17:57 rp02 systemd[1]: Starting Daily apt download activities...
Jun  7 17:18:46 rp02 systemd[1]: apt-daily.service: Deactivated successfully.
Jun  7 17:18:46 rp02 systemd[1]: Finished Daily apt download activities.
Jun  7 17:18:46 rp02 systemd[1]: apt-daily.service: Consumed 47.031s CPU time.
Jun  7 18:15:28 rp02 systemd[1]: Created slice User Slice of UID 1000.
Jun  7 18:15:28 rp02 systemd[1]: Starting User Runtime Directory /run/user/1000...
Jun  7 18:15:28 rp02 systemd[1]: Finished User Runtime Directory /run/user/1000.
Jun  7 18:15:28 rp02 systemd[1]: Starting User Manager for UID 1000...
Jun  7 18:15:30 rp02 systemd[5522]: Queued start job for default target Main User Target.
Jun  7 18:15:30 rp02 systemd[5522]: Created slice User Application Slice.
Jun  7 18:15:30 rp02 systemd[5522]: Reached target Paths.
Jun  7 18:15:30 rp02 systemd[5522]: Reached target Timers.
Jun  7 18:15:30 rp02 systemd[5522]: Starting D-Bus User Message Bus Socket...
Jun  7 18:15:30 rp02 systemd[5522]: Listening on GnuPG network certificate management daemon.
Jun  7 18:15:30 rp02 systemd[5522]: Listening on GnuPG cryptographic agent and passphrase cache (access for web browsers).
Jun  7 18:15:30 rp02 systemd[5522]: Listening on GnuPG cryptographic agent and passphrase cache (restricted).
Jun  7 18:15:30 rp02 systemd[5522]: Listening on GnuPG cryptographic agent (ssh-agent emulation).
Jun  7 18:15:30 rp02 systemd[5522]: Listening on GnuPG cryptographic agent and passphrase cache.
Jun  7 18:15:30 rp02 systemd[5522]: Listening on debconf communication socket.
Jun  7 18:15:30 rp02 systemd[5522]: Listening on REST API socket for snapd user session agent.
Jun  7 18:15:30 rp02 systemd[5522]: Listening on D-Bus User Message Bus Socket.
Jun  7 18:15:30 rp02 systemd[5522]: Reached target Sockets.
Jun  7 18:15:30 rp02 systemd[5522]: Reached target Basic System.
Jun  7 18:15:30 rp02 systemd[5522]: Reached target Main User Target.
Jun  7 18:15:30 rp02 systemd[5522]: Startup finished in 2.101s.
Jun  7 18:15:30 rp02 systemd[1]: Started User Manager for UID 1000.
Jun  7 18:15:30 rp02 systemd[1]: Started Session 59 of User fernando.
Jun  7 18:17:01 rp02 CRON[5619]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Jun  7 18:23:42 rp02 avahi-daemon[699]: Withdrawing address record for yyyy:yyyy:yyyy:yyyy:xxxx:xxxx:xxxx:xxxx on eth0.
Jun  7 18:23:42 rp02 avahi-daemon[699]: Leaving mDNS multicast group on interface eth0.IPv6 with address yyyy:yyyy:yyyy:yyyy:xxxx:xxxx:xxxx:xxxx.
Jun  7 18:23:42 rp02 avahi-daemon[699]: Joining mDNS multicast group on interface eth0.IPv6 with address fe80::xxxx:xxxx:xxxx:xxxx.
Jun  7 18:23:42 rp02 avahi-daemon[699]: Registering new address record for fe80::xxxx:xxxx:xxxx:xxxx on eth0.*.
Jun  7 18:29:48 rp02 systemd[1]: Starting Download data for packages that failed at package install time...
Jun  7 18:29:48 rp02 systemd[1]: update-notifier-download.service: Deactivated successfully.
Jun  7 18:29:48 rp02 systemd[1]: Finished Download data for packages that failed at package install time.
Jun  7 18:32:43 rp02 avahi-daemon[699]: Leaving mDNS multicast group on interface eth0.IPv6 with address fe80::xxxx:xxxx:xxxx:xxxx.
Jun  7 18:32:43 rp02 avahi-daemon[699]: Joining mDNS multicast group on interface eth0.IPv6 with address yyyy:yyyy:yyyy:yyyy:xxxx:xxxx:xxxx:xxxx.
Jun  7 18:32:43 rp02 avahi-daemon[699]: Registering new address record for yyyy:yyyy:yyyy:yyyy:xxxx:xxxx:xxxx:xxxx on eth0.*.
Jun  7 18:32:43 rp02 avahi-daemon[699]: Withdrawing address record for fe80::xxxx:xxxx:xxxx:xxxx on eth0.
Jun  7 18:35:29 rp02 snapd[721]: storehelpers.go:722: cannot refresh: snap has no updates available: "certbot", "core20", "lxd", "snapd"
Jun  7 18:35:29 rp02 snapd[721]: autorefresh.go:539: auto-refresh: all snaps are up-to-date
Jun  7 18:39:57 rp02 systemd[1]: Starting Cleanup of Temporary Directories...
Jun  7 18:39:57 rp02 systemd[1]: systemd-tmpfiles-clean.service: Deactivated successfully.
Jun  7 18:39:57 rp02 systemd[1]: Finished Cleanup of Temporary Directories.
Jun  7 18:42:07 rp02 avahi-daemon[699]: Withdrawing address record for yyyy:yyyy:yyyy:yyyy:xxxx:xxxx:xxxx:xxxx on eth0.
Jun  7 18:42:07 rp02 avahi-daemon[699]: Leaving mDNS multicast group on interface eth0.IPv6 with address yyyy:yyyy:yyyy:yyyy:xxxx:xxxx:xxxx:xxxx.
Jun  7 18:42:07 rp02 avahi-daemon[699]: Joining mDNS multicast group on interface eth0.IPv6 with address fe80::xxxx:xxxx:xxxx:xxxx.
Jun  7 18:42:07 rp02 avahi-daemon[699]: Registering new address record for fe80::xxxx:xxxx:xxxx:xxxx on eth0.*.
Jun  7 18:43:54 rp02 avahi-daemon[699]: Leaving mDNS multicast group on interface eth0.IPv6 with address fe80::xxxx:xxxx:xxxx:xxxx.
Jun  7 18:43:54 rp02 avahi-daemon[699]: Joining mDNS multicast group on interface eth0.IPv6 with address yyyy:yyyy:yyyy:yyyy:xxxx:xxxx:xxxx:xxxx.
Jun  7 18:43:54 rp02 avahi-daemon[699]: Registering new address record for yyyy:yyyy:yyyy:yyyy:xxxx:xxxx:xxxx:xxxx on eth0.*.
Jun  7 18:43:54 rp02 avahi-daemon[699]: Withdrawing address record for fe80::xxxx:xxxx:xxxx:xxxx on eth0.
Jun  7 18:53:03 rp02 avahi-daemon[699]: Withdrawing address record for yyyy:yyyy:yyyy:yyyy:xxxx:xxxx:xxxx:xxxx on eth0.
Jun  7 18:53:03 rp02 avahi-daemon[699]: Leaving mDNS multicast group on interface eth0.IPv6 with address yyyy:yyyy:yyyy:yyyy:xxxx:xxxx:xxxx:xxxx.
Jun  7 18:53:03 rp02 avahi-daemon[699]: Joining mDNS multicast group on interface eth0.IPv6 with address fe80::xxxx:xxxx:xxxx:xxxx.
Jun  7 18:53:03 rp02 avahi-daemon[699]: Registering new address record for fe80::xxxx:xxxx:xxxx:xxxx on eth0.*.
Jun  7 19:02:33 rp02 avahi-daemon[699]: Leaving mDNS multicast group on interface eth0.IPv6 with address fe80::xxxx:xxxx:xxxx:xxxx.
Jun  7 19:02:33 rp02 avahi-daemon[699]: Joining mDNS multicast group on interface eth0.IPv6 with address yyyy:yyyy:yyyy:yyyy:xxxx:xxxx:xxxx:xxxx.
Jun  7 19:02:33 rp02 avahi-daemon[699]: Registering new address record for yyyy:yyyy:yyyy:yyyy:xxxx:xxxx:xxxx:xxxx on eth0.*.
Jun  7 19:02:33 rp02 avahi-daemon[699]: Withdrawing address record for fe80::xxxx:xxxx:xxxx:xxxx on eth0.
Jun  7 19:03:10 rp02 avahi-daemon[699]: Withdrawing address record for yyyy:yyyy:yyyy:yyyy:xxxx:xxxx:xxxx:xxxx on eth0.
Jun  7 19:03:10 rp02 avahi-daemon[699]: Leaving mDNS multicast group on interface eth0.IPv6 with address yyyy:yyyy:yyyy:yyyy:xxxx:xxxx:xxxx:xxxx.
Jun  7 19:03:10 rp02 avahi-daemon[699]: Joining mDNS multicast group on interface eth0.IPv6 with address fe80::xxxx:xxxx:xxxx:xxxx.
Jun  7 19:03:10 rp02 avahi-daemon[699]: Registering new address record for fe80::xxxx:xxxx:xxxx:xxxx on eth0.*.
Jun  7 19:10:43 rp02 avahi-daemon[699]: Leaving mDNS multicast group on interface eth0.IPv6 with address fe80::xxxx:xxxx:xxxx:xxxx.
Jun  7 19:10:43 rp02 avahi-daemon[699]: Joining mDNS multicast group on interface eth0.IPv6 with address yyyy:yyyy:yyyy:yyyy:xxxx:xxxx:xxxx:xxxx.
Jun  7 19:10:43 rp02 avahi-daemon[699]: Registering new address record for yyyy:yyyy:yyyy:yyyy:xxxx:xxxx:xxxx:xxxx on eth0.*.
Jun  7 19:10:43 rp02 avahi-daemon[699]: Withdrawing address record for fe80::xxxx:xxxx:xxxx:xxxx on eth0.
Jun  7 19:13:35 rp02 systemd[1]: Starting Service for snap application certbot.renew...
Jun  7 19:13:42 rp02 systemd[1]: snap.certbot.renew.service: Deactivated successfully.
Jun  7 19:13:42 rp02 systemd[1]: Finished Service for snap application certbot.renew.
Jun  7 19:13:42 rp02 systemd[1]: snap.certbot.renew.service: Consumed 6.641s CPU time.
Jun  7 19:17:01 rp02 CRON[5717]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Jun  7 19:19:41 rp02 avahi-daemon[699]: Withdrawing address record for yyyy:yyyy:yyyy:yyyy:xxxx:xxxx:xxxx:xxxx on eth0.
Jun  7 19:19:41 rp02 avahi-daemon[699]: Leaving mDNS multicast group on interface eth0.IPv6 with address yyyy:yyyy:yyyy:yyyy:xxxx:xxxx:xxxx:xxxx.
Jun  7 19:19:41 rp02 avahi-daemon[699]: Joining mDNS multicast group on interface eth0.IPv6 with address fe80::xxxx:xxxx:xxxx:xxxx.
Jun  7 19:19:41 rp02 avahi-daemon[699]: Registering new address record for fe80::xxxx:xxxx:xxxx:xxxx on eth0.*.
Jun  7 19:20:55 rp02 avahi-daemon[699]: Leaving mDNS multicast group on interface eth0.IPv6 with address fe80::xxxx:xxxx:xxxx:xxxx.
Jun  7 19:20:55 rp02 avahi-daemon[699]: Joining mDNS multicast group on interface eth0.IPv6 with address yyyy:yyyy:yyyy:yyyy:xxxx:xxxx:xxxx:xxxx.

The fact that a reboot fixes it for 2 days makes it hard to try anything

Further investigation and turning systemd into debug mode shows my problem is basically https://archlinuxarm.org/forum/viewtopic.php?f=60&t=15566&sid=cf1d054d50c16df15c74079e2a6871dd&start=10. But this does not help me as systemd does not have an version 248 that I can downgrade to

1
  • Same issue here ... working for like two days and then breaking again...
    – V O
    Feb 5 at 17:41

0

You must log in to answer this question.

Browse other questions tagged .