Quantcast
Viewing all articles
Browse latest Browse all 3423

IPv6 address repeatedly registered and withdrawn

I've been trying to track down an issue which ultimately causes avahi-daemon to spam my syslog with messages similar these:

Code:

2023-12-19T19:22:15.143458+01:00 ... avahi-daemon[458]: Registering new address record for 2a02:####:####:####:2f89:f9d2:504f:595d on wlan0.*.2023-12-19T19:22:16.181261+01:00 ... avahi-daemon[458]: Withdrawing address record for 2a02:####:####:####:2f89:f9d2:504f:595d on wlan0.2023-12-19T19:22:18.011506+01:00 ... avahi-daemon[458]: Registering new address record for 2a02:####:####:####:2f89:f9d2:504f:595d on wlan0.*.2023-12-19T19:22:19.240632+01:00 ... avahi-daemon[458]: Withdrawing address record for 2a02:####:####:####:2f89:f9d2:504f:595d on wlan0.
Some research suggests that faulty IPv6 Router Advertisements may be the cause of this, but I don't think so. The RAs contain zero values for the prefix lifetimes, but that's fine.

Code:

$ rdisc6 -1 wlan0Soliciting ff02::2 (ff02::2) on wlan0...Hop limit                 :           64 (      0x40)Stateful address conf.    :          YesStateful other conf.      :          YesMobile home agent         :           NoRouter preference         :       mediumNeighbor discovery proxy  :           NoRouter lifetime           :         1800 (0x00000708) secondsReachable time            :      3600000 (0x0036ee80) millisecondsRetransmit time           :  unspecified (0x00000000) Recursive DNS server     : 2a02:####:####:####:f2af:85ff:fe11:70d  DNS server lifetime     :          300 (0x0000012c) seconds Prefix                   : 2a02:####:####:####::/64  On-link                 :          Yes  Autonomous address conf.:          Yes  Valid time              :            0 (0x00000000) seconds  Pref. time              :            0 (0x00000000) seconds Route                    : ::/0  Route preference        :       medium  Route lifetime          :         1800 (0x00000708) seconds Source link-layer address: ##:##:##:##:##:## from fe80::f2af:85ff:fe11:70d 
Along the way I noticed that the lifetimes reported by ip address are sometimes a second or so higher than the values sent in the router advertisement. If the values are non-zero, that may or may not serve some purpose, but in the case of zero-valued lifetimes, that seems to cause the preferred_lft to become 1, which revives the deprecated address, only to immediately expire again. What could be the cause of this?

I can reproduce this on 2 different machines, with Debian 12 and Raspberry Pi OS, but I wasn't able to reproduce it on Arch. The main problem here is I don't know where to look to diagnose this further. Any suggestions?

See also my related question on stack overflow.

Statistics: Posted by bplu4t2f — 2023-12-27 12:13 — Replies 5 — Views 166



Viewing all articles
Browse latest Browse all 3423

Trending Articles