Avahi-daemon withdraws address record

[Matt Schulte]

For some reason, if I leave my Ubuntu VM up for a prolonged period of time the machine will lose connection to the network. ip addr shows that the nic port no longer has an address and an examination of the syslog shows this:

May 27 14:19:38 matt-VirtualBox avahi-daemon[590]: Withdrawing address record for 10.0.2.15 on enp0s3.
May 27 14:19:38 matt-VirtualBox avahi-daemon[590]: Leaving mDNS multicast group on interface enp0s3.IPv4 with address 10.0.2.15.
May 27 14:19:38 matt-VirtualBox avahi-daemon[590]: Interface enp0s3.IPv4 no longer relevant for mDNS.

for no known reason.

The only reliable way to get the network to come back (that I have found) is a full reboot.

ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: avahi-daemon 0.6.32~rc+dfsg-1ubuntu2
ProcVersionSignature: Ubuntu 4.4.0-22.40-generic 4.4.8
Uname: Linux 4.4.0-22-generic x86_64
ApportVersion: 2.20.1-0ubuntu2
Architecture: amd64
CurrentDesktop: Unity
Date: Fri May 27 15:11:34 2016
InstallationDate: Installed on 2015-10-22 (218 days ago)
InstallationMedia: Ubuntu 15.10 "Wily Werewolf" - Release amd64 (20151021)
SourcePackage: avahi
UpgradeStatus: Upgraded to xenial on 2016-03-30 (58 days ago)

[Trent Lloyd (lathiat)]

Avahi is not the one actively withdrawing the address, this log message is a reaction to the address record being removed from the system.. it withdraws the mDNS "record" for this address.

Most likely theory for this is that DHCP is deciding to drop the address for some reason (lease expired and couldn't renew) or something else like that. In any case issue will be Network Manager related more than Avahi.

[Matt Schulte (gimpyestrada)]

Maybe the problem is not in Avahi, but it is still a problem somewhere.

This bug continues to plague my vm. Today I noticed that if I try to interact with the network port, I am told that it is unknown, does this have something to do with it?

matt@matt-VirtualBox:~$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    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: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 08:00:27:77:bd:5b brd ff:ff:ff:ff:ff:ff
    inet6 fe80::ac78:e0ca:b9f3:5266/64 scope link
       valid_lft forever preferred_lft forever
matt@matt-VirtualBox:~$ ifdown enp0s3
Unknown interface enp0s3

[Pavel Cervinka (pce-k)]

I have the same problem; syslog doesn't tell much, but kern.log tells a bit more - "something" is restarting NetworkManager, and the restart results in losing network connection(s); see below; I have standard ubuntu 16.04 LTS 64bit kept up-to-date as a VM within VirtualBox with Win7/64 host and the latest Vbox version (this had been happening across several Vbox updates; but on the same Vbox version, it wasn't happening on ubuntu 14.10 VM until I removed that and installed a brand new 16.04 from scratch). I hoped the 16.04 would soon get a patch fixing this but that never happened. I have both the host and the VM running 24/7 and the frequency of losing the network is about this - ignore November/14, that was obviously unusual and not related to the problem.

root@ostws0116886lu:~# LC_ALL=C egrep "whoopsi.*offline" /var/log/syslog*
/var/log/syslog:Nov 22 15:57:38 ostws0116886lu whoopsie[617]: [15:57:38] offline
/var/log/syslog:Nov 23 15:57:58 ostws0116886lu whoopsie[617]: [15:57:58] offline
/var/log/syslog:Nov 25 09:21:11 ostws0116886lu whoopsie[617]: [09:21:11] offline
/var/log/syslog.1:Nov 15 21:41:08 ostws0116886lu whoopsie[663]: [21:41:08] offline
/var/log/syslog.1:Nov 16 22:02:29 ostws0116886lu whoopsie[663]: [22:02:29] offline

root@ostws0116886lu:~# LC_ALL=C xzegrep "whoopsi.*offline" /var/log/syslog*.xz
/var/log/syslog.2.xz:Nov 6 09:47:04 ostws0116886lu whoopsie[26233]: [09:47:04] offline
/var/log/syslog.2.xz:Nov 9 08:03:06 ostws0116886lu whoopsie[637]: [08:03:06] offline
/var/log/syslog.2.xz:Nov 9 08:04:43 ostws0116886lu whoopsie[640]: [08:04:43] offline
/var/log/syslog.2.xz:Nov 10 15:57:30 ostws0116886lu whoopsie[685]: [15:57:30] offline
/var/log/syslog.2.xz:Nov 14 10:02:59 ostws0116886lu whoopsie[641]: [10:02:59] offline
/var/log/syslog.2.xz:Nov 14 10:03:31 ostws0116886lu whoopsie[626]: [10:03:31] offline
/var/log/syslog.2.xz:Nov 14 10:25:23 ostws0116886lu whoopsie[721]: [10:25:23] offline
/var/log/syslog.2.xz:Nov 14 10:26:02 ostws0116886lu whoopsie[618]: [10:26:02] offline
/var/log/syslog.2.xz:Nov 14 10:26:25 ostws0116886lu whoopsie[656]: [10:26:25] offline
/var/log/syslog.2.xz:Nov 14 10:46:50 ostws0116886lu whoopsie[663]: [10:46:50] offline
/var/log/syslog.3.xz:Nov 2 11:53:15 ostws0116886lu whoopsie[666]: [11:53:15] offline
/var/log/syslog.3.xz:Nov 3 11:53:26 ostws0116886lu whoopsie[666]: [11:53:26] offline
/var/log/syslog.3.xz:Nov 4 12:02:52 ostws0116886lu whoopsie[666]: [12:02:52] offline
/var/log/syslog.4.xz:Oct 25 02:02:43 ostws0116886lu whoopsie[693]: [02:02:43] offline
/var/log/syslog.4.xz:Oct 27 15:45:18 ostws0116886lu whoopsie[693]: [15:45:18] offline
/var/log/syslog.4.xz:Oct 28 10:21:56 ostws0116886lu whoopsie[647]: [10:21:56] offline
/var/log/syslog.4.xz:Oct 29 10:22:09 ostws0116886lu whoopsie[647]: [10:22:09] offline

kern.log:
---
Nov 24 09:20:58 ostws0116886lu NetworkManager[632]: <info> [1479979258.9094] caught SIGTERM, shutting down normally.
Nov 24 09:20:58 ostws0116886lu NetworkManager[632]: <info> [1479979258.9662] exiting (success)
Nov 24 09:20:59 ostws0116886lu NetworkManager[3470]: <info> [1479979259.2438] NetworkManager (version 1.2.2) is starting...
Nov 24 09:20:59 ostws0116886lu NetworkManager[34...

[Pavel Cervinka (pce-k)]

... I'm sure it's something between ubuntu and VirtualBox, but it'd be really nice to not have the usual one throwing the blame on the other, for once ...

[Ville (villen)]

I am having the same problem on Ubuntu 16.04. I am NOT using VM.

On syslog:

avahi-daemon[1264]: Withdrawing address record for 192.168.0.101 on enp2s0.
avahi-daemon[1264]: Leaving mDNS multicast group on interface enp2s0.IPv4 with address 192.168.0.101.
avahi-daemon[1264]: Interface enp2s0.IPv4 no longer relevant for mDNS.

Also running ifconfig shows that enp2s0 has no ipv4 address.

Trying sudo ifdown enp2s0 gives:

Unknown interface enp2s0

So far I have been able to fix this in xfce by going to Settings -> Network Connections,
selecting wired connection and deleting it. This did renew the connection instantly.

I also managed to renew it in UNITY by right clicking network icon on taskbar(?) and disabling network and then enabling it again.

[gfxcoder (gfxcoder)]

I am having the same problem on Kubuntu 16.04 machine, not in a VM.

In syslog:
   Mar 13 11:18:04 gfx-desktop avahi-daemon[1040]: Withdrawing address record for 10.122.2.113 on enp3s0.
   Mar 13 11:18:04 gfx-desktop avahi-daemon[1040]: Leaving mDNS multicast group on interface enp3s0.IPv4 with address 10.122.2.113.
   Mar 13 11:18:04 gfx-desktop avahi-daemon[1040]: Interface enp3s0.IPv4 no longer relevant for mDNS.
   ...
   Mar 13 11:18:04 gfx-desktop whoopsie[1056]: [11:18:04] Cannot reach: https://daisy.ubuntu.com
   Mar 13 11:18:04 gfx-desktop whoopsie[1056]: [11:18:04] offline

ifconfig would show an inet6 address, but no inet address (IPv4).

I am able to recover by plugging the network cable out and then back in.

Also, I can recover by:
   sudo ifconfig enp3s0 down
   sudo ifconfig ens3s0 up

I have tried two different NICs.

After calling two ifconfig lines above, syslog has [see attached file].

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Steve Chadsey (schadsey)]

I am having the same issue, not in a VM. Ubuntu 16.04.1 LTS. eth0 is a wired network controller. I've attached a tar file containing:
- relevant syslog messages
- output of 'ethtool eht0'
- output of 'ethtool -i eth0'
- output of 'lspci -vvv'

I'm not sure what other information would be relevant but am happy to provide it on request, either when the system is in the problem state or otherwise.

I recover the situation by clicking the "Wired connection 1" in the network indicator panel.

Clearly there are at least 3 problems here:
1. The network connection is lost
2. There is no reason given for the loss of connection
3. The connection is not automatically recovered

[Iwish (albogdashkin)]

I am having the same issue, not in a VM.
Apr 12 02:52:44 HPfax avahi-daemon[773]: Withdrawing address record for 192.168.1.68 on enp5s0.
Apr 12 02:52:44 HPfax avahi-daemon[773]: Leaving mDNS multicast group on interface enp5s0.IPv4 with address 192.168.1.68.
Apr 12 02:52:44 HPfax avahi-daemon[773]: Interface enp5s0.IPv4 no longer relevant for mDNS.
Apr 12 02:52:46 HPfax whoopsie[752]: [02:52:46] Cannot reach: https://daisy.ubuntu.com
Apr 12 02:52:46 HPfax whoopsie[752]: [02:52:46] offline
Apr 12 02:53:26 HPfax org.freedesktop.Notifications[1509]: ** (notify-osd:2208): WARNING **: stack_close_notification_handler(): notification id == 0, likely wrong

[ronny (ronny63)]

Hi,

same problem here with Ubuntu Budgie 17.04 (clean installation). Not VM. Ethernet, but I have clean installation of Ubuntu Budgie on laptop and I had once problem with connection also there (wifi), but I didnt not check the logs.. I will report it here if it happens and if same messages are in logs.

dub 17 12:56:29 budgie avahi-daemon[1038]: Withdrawing address record for 192.168.0.32 on enp3s0.
dub 17 12:56:29 budgie avahi-daemon[1038]: Leaving mDNS multicast group on interface enp3s0.IPv4 with address 192.168.0.32.
dub 17 12:56:29 budgie avahi-daemon[1038]: Interface enp3s0.IPv4 no longer relevant for mDNS.

[Gabriel.C (g4bb3bf2)]

Exact same issue here, recently done dist-upgrade from 14.04 LTS to 16.04, I did not have this problem at all before. Not running on VM.

Linux server 4.4.0-75-generic #96-Ubuntu SMP Thu Apr 20 09:56:33 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

Using Wired ethernet, happens 2-3 times at least a week and need to reboot.

others have other NIC than Realtek ?
RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
driver=r8169 driverversion=2.3LK-NAPI firmware=rtl8168e-3_0.0.4 03/27/12

syslog not showing any hints to what happened other than already mentioned above.

[Maarten Visscher (mhvis)]

Can confirm, have the same problem: server loses connection after a while with no usable log entries except for the avahi-daemon message.

I am however not using Ubuntu, but Arch. Also not in a VM.

The NIC is for me the same: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 02).

[Chuck Hawley (crh0831)]

Same symptoms, same result on a headless always-on box running 16.04. Made worse by the fact that I have to hard-power off the box and hook it up to monitor for troubleshooting. Every couple weeks the machine will lose connection to the network.

Last time I thought I lost the on-board NIC and went and bought/installed a new NIC card (another Realtek). Two weeks later, same result: syslog shows this:

May 24 22:40:14 phaedrus avahi-daemon[857]: Withdrawing address record for 192.168.0.201 on enp4s1.
May 24 22:40:14 phaedrus avahi-daemon[857]: Leaving mDNS multicast group on interface enp4s1.IPv4 with address 192.168.0.201.
May 24 22:40:14 phaedrus avahi-daemon[857]: Interface enp4s1.IPv4 no longer relevant for mDNS.

## System:

Host: phaedrus Kernel: 4.4.0-78-generic x86_64 (64 bit) Console: tty 9 Distro: Ubuntu 16.04 xenial

## Network: (from `inxi -F`)

Card-1: Device 000c:d051
IF: N/A state: N/A speed: N/A duplex: N/A mac: N/A
Card-2: Realtek RTL8169 PCI Gigabit Ethernet Controller driver: r8169
IF: enp4s1 state: up speed: 1000 Mbps duplex: full mac: 00:0a:cd:2c:93:5f

Looks like it might be Realtek 8168/9 related?

[Wang Chenxi (samsonwang)]

Same problem.
About 1 time per week.

Is there any bug fix or workaround yet?

[Trent Lloyd (lathiat)]

To debug this issue requires more information, the log messages from avahi itself are simply a "symptom" of the fact the network address was deleted.

For any affected system we need to know
 (1) How your network is setup, e.g. /etc/network/interfaces, Network-Manager, etc. Plus a copy of the relevant configuration file.
 (2) A full copy of the syslog file when the issue occurred including at least a few hours before the issue. There may be some other log items such as related to DHCP etc. If you reboot, the logs may get rotated to /var/log/syslog.1
 (3) It would be helpful to know that if you attempt to reconfigure the network, does it then work. e.g. if you do ifdown, then ifup. Or try a manual "dhclient eth0" (or whatever the interface name is)

I am imagining two main scenarios here, either
  (a) You are using DHCP and the DHCP lease fails for some reason causing it to be removed from the interface. Perhaps dhclient fails, or the DHCP server is temporarily unavailable. Hopefully syslog might have some info there.

  (b) The network card itself stops passing traffic due to a driver bug.. given everyone is reporting issues on realtek this doesn't seem unlikely. To narrow that down we really need someone to try re-configure the IP, try adding an IP manually/statically and then running tcpdump to see if any traffic is hitting the machine. You could also try perhaps remove the kernel module and insert it again.

[Leen Droogendijk (eldane)]

Same problem. Using Mint. No VM involved.
Switched from Windows to Linux just a few days ago.
This occurred two times in three days now.
Never did anything network related, so all my settings should be the default ones.

$ sudo lshw -class network
  *-network
       description: Ethernet interface
       product: RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
       vendor: Realtek Semiconductor Co., Ltd.
       physical id: 0
       bus info: pci@0000:03:00.0
       logical name: enp3s0
       version: 0c
       serial: e0:3f:49:e8:4f:66
       size: 1Gbit/s
       capacity: 1Gbit/s
       width: 64 bits
       clock: 33MHz
       capabilities: pm msi pciexpress msix vpd bus_master cap_list ethernet physical tp mii 10bt 10bt-fd 100bt 100bt-fd 1000bt 1000bt-fd autonegotiation
       configuration: autonegotiation=on broadcast=yes driver=r8169 driverversion=2.3LK-NAPI duplex=full firmware=rtl8168g-2_0.0.1 02/06/13 ip=192.168.2.1 latency=0 link=yes multicast=yes port=MII speed=1Gbit/s
       resources: irq:27 ioport:d000(size=256) memory:f7100000-f7100fff memory:f2100000-f2103fff

[Steve Chadsey (schadsey)]

This issue is not limited to Realtek as it occurs on my system with an Intel ethernet controller (see https://bugs.launchpad.net/ubuntu/+source/avahi/+bug/1586528/comments/9).

00:19.0 Ethernet controller: Intel Corporation Ethernet Connection (2) I218-V
 DeviceName: Onboard LAN
 Subsystem: ASUSTeK Computer Inc. Ethernet Connection (2) I218-V
 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
 Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
 Latency: 0
 Interrupt: pin A routed to IRQ 28
 Region 0: Memory at dfd00000 (32-bit, non-prefetchable) [size=128K]
 Region 1: Memory at dfd3c000 (32-bit, non-prefetchable) [size=4K]
 Region 2: I/O ports at f080 [size=32]
 Capabilities: <access denied>
 Kernel driver in use: e1000e
 Kernel modules: e1000e

I don't have a workaround but the following is what I use to help recover. It pings my gateway periodically, and if it can't it attempts to restart networking.

In /etc/crontab:

# check networking
*/10 * * * * root /usr/local/bin/check_reset_network.sh >> /var/log/check_reset_network.log

/usr/local/bin/check_reset_network.sh:

---[start]-----
#!/bin/bash

echo "`date` $0 starting"

gw=192.168.1.254

echo "Trying to ping gw $gw"
out=$(ping -c 5 $gw 2>&1)

if [ $? -eq 0 ]; then
  echo "Success"
else
  echo "Failed to ping gw $gw"
  echo "Trying again in 20s"

  sleep 20

  out=$(ping -c 5 $gw 2>&1)

  if [ $? -ne 0 ]; then
    echo "Failed to ping gw $gw"
    echo "Restarting networking"

    sudo service network-manager restart

    echo "Waiting 20s to recheck network"
    sleep 20

    out=$(ping -c 5 $gw 2>&1)

    if [ $? -eq 0 ]; then
      echo "Success; sending mail"
      echo "Restarted networking" | mail your_email_addr
    else
      echo "Failed. You're fucked."
    fi
  fi
fi

echo "Checking for default route"

out=$(/sbin/ip route | egrep '^default')
if [ $? -eq 0 ]; then
  echo "Success"
else
  echo "Failed to find default route. Adding it."
  /sbin/route add default gw 192.168.1.254

  if [ $? -eq 0 ]; then
    echo "Success; sending mail"
    echo "Added default route" | mail your_email_addr
  else
      echo "Failed. You're fucked."
  fi
fi

echo "`date` $0 done"
---[end]-----

[niedzielski (niedzielski)]

I've had this issue constantly since upgrading to Ubuntu v17.04 (not a VM). It was unusably bad. Fortunately, disabling IPv6 has been a consistently successful workaround for me:

1 Add the following /etc/sysctl.conf:

  net.ipv6.conf.all.disable_ipv6 = 1
  net.ipv6.conf.default.disable_ipv6 = 1
  net.ipv6.conf.lo.disable_ipv6 = 1

2 Run `sudo sysctl -p` after rebooting, cycling Wi-Fi, or changing networks.

I feel silly writing this because I'm certain there's a better fix but it looks like other folks have tried similar workarounds.

https://askubuntu.com/questions/886107/google-chrome-error-21-neterr-network-changed
https://askubuntu.com/questions/440649/how-to-disable-ipv6-in-ubuntu-14-04

[Georg Acher (georg.a)]

Same here with 16.04.2 (4.8.0-58-generic x86_64, no VM) and Realtek8111 (PCI 10ec:8168 rev 06). Worked before with 12.04, now it's shutting down the interface every few days.

Regarding the Networkmanager restart: Not for me, the PID is still the same.

Maybe the timing from the latest event may help:

Jul 23 13:51:19 braindead5 dhclient[26468]: DHCPREQUEST of 192.168.0.5 on enp8s0 to 192.168.0.1 port 67 (xid=0x75dc0193)
Jul 23 13:51:19 braindead5 dhclient[26468]: DHCPACK of 192.168.0.5 from 192.168.0.1
Jul 23 13:51:19 braindead5 dhclient[26468]: bound to 192.168.0.5 -- renewal in 17447 seconds.

So the IP is valid for more than 4h. But about an hour later:

Jul 23 14:57:51 braindead5 avahi-daemon[907]: Withdrawing address record for 192.168.0.5 on enp8s0.
Jul 23 14:57:51 braindead5 avahi-daemon[907]: Leaving mDNS multicast group on interface enp8s0.IPv4 with address 192.168.0.5.
Jul 23 14:57:51 braindead5 avahi-daemon[907]: Interface enp8s0.IPv4 no longer relevant for mDNS.
Jul 23 14:57:51 braindead5 org.kde.kdeconnect[1675]: "No such interface 'org.freedesktop.DBus.Properties' on object at path /"
Jul 23 14:57:56 braindead5 kernel: [1879701.611525] nfs: server 192.168.0.1 not responding, timed out

The interface was shut down (no IP, only visible with ifconfig -a), but it had link state (green LED). There were no other messages regarding Networkmanager etc. at that time.

It's hard to tell if the NFS problems are caused by the avahi-stuff or both share the same root cause. In my experience, NFS usually "finds" missing connectivity very fast, so it should complain before avahi... Also on all other occurences the avahi message was before NFS.

I've now stopped the avahi-daemon. If it happens again, I will look if dhclient runs and if there are increasing RX packets and visible broadcast data from other hosts at the dead interface.

[Alex (normadize)]

Another unhappy bunny here. 16.04.02, 4.4.0-83-generic

The DHCP lease from the router is 10 minutes. Ubuntu just doesn't renew it. After exactly 10 minutes this happens:

Jul 29 03:58:21 airwolf avahi-daemon[751]: Withdrawing address record for 192.168.1.22 on enp0s31f6.
Jul 29 03:58:21 airwolf avahi-daemon[751]: Leaving mDNS multicast group on interface enp0s31f6.IPv4 with address 192.168.1.22.
Jul 29 03:58:21 airwolf avahi-daemon[751]: Interface enp0s31f6.IPv4 no longer relevant for mDNS.

Also, /var/lib/dhcp/dhclient.leases is 0 bytes

[Graham Bosworth (graham-bozikins)]

I am seeing the same problem on a physical host running Linux Mint. I too have found that clicking the network icon to toggle it off and back on can restore connections. Additionally, I have found that the connection may be restored without intervention, given sufficient time (potentially hours). Sorry that this is a long post - when trying to add an attachment, the U.R.L. was not found. I have tried to provide anything that may be relevant. The connection was lost at 03:57:51, and regained at 04:24.

The computers featured are yoyo, 192.168.42.187, 00:25:64:72:72:14, the Linux Mint computer, and kevin, 192.168.42.129, 00:50:04:23:f7:80, the D.H.C.P. server and Internet gateway.

[LinuxMint] graham@yoyo $ cat /etc/network/interfaces
# interfaces(5) file used by ifup(8) and ifdown(8)
auto lo
iface lo inet loopback
Tue Aug 22 17:57:47 ~

[LinuxMint] graham@yoyo $ lspci | grep -i "net"
09:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8040 PCI-E Fast Ethernet Controller (rev 13)
0c:00.0 Network controller: Broadcom Corporation BCM4312 802.11b/g LP-PHY (rev 01)
Tue Aug 22 17:59:23 ~

The Broadcom wireless adaptor is not active.

[LinuxMint] graham@yoyo $ cat /etc/os-release
NAME="Linux Mint"
VERSION="18 (Sarah)"
ID=linuxmint
ID_LIKE=ubuntu
PRETTY_NAME="Linux Mint 18"
VERSION_ID="18"
HOME_URL="http://www.linuxmint.com/"
SUPPORT_URL="http://forums.linuxmint.com/"
BUG_REPORT_URL="http://bugs.launchpad.net/linuxmint/"
UBUNTU_CODENAME=xenial
Tue Aug 22 17:48:57 ~

[LinuxMint] graham@yoyo $ uname -a
Linux yoyo 4.4.0-21-generic #37-Ubuntu SMP Mon Apr 18 18:33:37 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
Tue Aug 22 18:04:00 ~

Here is a excerpt from kern.log, showing that the D.H.C.P. lease was not renewed and the network connection was lost:-
Aug 21 03:00:30 yoyo NetworkManager[1049]: <info> [1503280830.6457] dhcp4 (eth0): state changed bound -> bound
Aug 21 03:13:25 yoyo NetworkManager[1049]: <info> [1503281605.4009] address 192.168.42.187
Aug 21 03:13:25 yoyo NetworkManager[1049]: <info> [1503281605.4009] plen 25 (255.255.255.128)
Aug 21 03:13:25 yoyo NetworkManager[1049]: <info> [1503281605.4010] gateway 192.168.42.129
Aug 21 03:13:25 yoyo NetworkManager[1049]: <info> [1503281605.4010] server identifier 192.168.42.129
Aug 21 03:13:25 yoyo NetworkManager[1049]: <info> [1503281605.4010] lease time 1800
Aug 21 03:13:25 yoyo NetworkManager[1049]: <info> [1503281605.4010] nameserver '192.168.42.129'
Aug 21 03:13:25 yoyo NetworkManager[1049]: <info> [1503281605.4011] nameserver '192.168.42.248'
Aug 21 03:13:25 yoyo NetworkManager[1049]: <info> [1503281605.4011] domain name 'example.net'
Aug 21 03:13:25 yoyo NetworkManager[1049]: <info> [1503281605.5497] dhcp4 (eth0
): state changed bound -> bound
Aug 21 03:27:49 yoyo NetworkManager[1049]: <info> [1503282469.5210] address 192.168.42.187
Aug 21 03:27:49 yoyo NetworkManager[1049]: <info> [1503282469.5211] plen 25 (255.255.255.128)
Aug 21 03:27:49 yoyo NetworkManager[1049]: <info> [1503282469.5211] gateway 192.168.42.129
Aug 21 03:27:49 yoyo NetworkManager[1049]: <info> [1503282469.5211] server identifier 192.168.42.129
Aug 21 03:27:49 yoyo NetworkManager[...

[Graham Bosworth (graham-bozikins)]

I have an update on the same problem as seen on another computer - ethel,
connected to an A.D.S.L. terminal adaptor (router). More details of the computer follow the commands and log excerpts. I think that this update suggests that avahi-daemon is the messenger, telling us that the NetworkManager has failed.

/var/log/syslog:Aug 24 09:49:13 ethel avahi-daemon[1042]: Withdrawing address record for 192.168.41.113 on enp2s0.
/var/log/syslog:Aug 24 09:49:13 ethel avahi-daemon[1042]: Leaving mDNS multicast group on interface enp2s0.IPv4 with address 192.168.41.113.
/var/log/syslog:Aug 24 09:49:13 ethel avahi-daemon[1042]: Interface enp2s0.IPv4 no longer relevant for mDNS.

... some hours later ....

[Mint] graham@ethel $ ip a s
...
2: enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether d4:3d:7e:9b:55:7a brd ff:ff:ff:ff:ff:ff
    inet6 fe80::af3c:f15c:e5aa:34ca/64 scope link
       valid_lft forever preferred_lft forever
Thu Aug 24 18:53:38 ~

[Mint] graham@ethel $ /etc/init.d/network-manager status
* NetworkManager.service - Network Manager
   Loaded: loaded (/lib/systemd/system/NetworkManager.service; enabled; vendor preset: enabled)
   Active: active (running) since Sat 2017-07-15 19:27:36 BST; 1 months 9 days ago
     Docs: man:NetworkManager(8)
 Main PID: 1034 (NetworkManager)
   CGroup: /system.slice/NetworkManager.service
           ├─1034 /usr/sbin/NetworkManager --no-daemon
           ├─1402 /usr/sbin/dnsmasq --no-resolv --keep-in-foreground --no-hos...
           └─4973 /sbin/dhclient -d -q -sf /usr/lib/NetworkManager/nm-dhcp-he...

Aug 24 18:53:47 ethel dhclient[4973]: send_packet: please consult README fi...s.
Aug 24 18:53:47 ethel dhclient[4973]: dhclient.c:2386: Failed to send 300 b...e.
Aug 24 18:53:58 ethel dhclient[4973]: DHCPREQUEST of 192.168.41.113 on enp2...c)
Aug 24 18:53:58 ethel dhclient[4973]: send_packet: Network is unreachable
Aug 24 18:53:58 ethel dhclient[4973]: send_packet: please consult README fi...s.
Aug 24 18:53:58 ethel dhclient[4973]: dhclient.c:2386: Failed to send 300 b...e.
Aug 24 18:54:07 ethel dhclient[4973]: DHCPREQUEST of 192.168.41.113 on enp2...c)
Aug 24 18:54:07 ethel dhclient[4973]: send_packet: Network is unreachable
Aug 24 18:54:07 ethel dhclient[4973]: send_packet: please consult README fi...s.
Aug 24 18:54:07 ethel dhclient[4973]: dhclient.c:2386: Failed to send 300 b...e.
Hint: Some lines were ellipsized, use -l to show in full.
Thu Aug 24 18:54:08 ~

[Mint] graham@ethel $ /etc/init.d/avahi-daemon status
* avahi-daemon.service - Avahi mDNS/DNS-SD Stack
   Loaded: loaded (/lib/systemd/system/avahi-daemon.service; enabled; vendor preset: enabled)
   Active: active (running) since Sat 2017-07-15 19:27:34 BST; 1 months 9 days ago
 Main PID: 1042 (avahi-daemon)
   Status: "avahi-daemon 0.6.32-rc starting up."
   CGroup: /system.slice/avahi-daemon.service
           ├─1042 avahi-daemon: running [ethel.local]
           └─1070 avahi-daemon: chroot helper

Aug 19 14:15:25 ethel avahi-daemon[1042]: Interface enp2s0.IPv6 no longer re....
Aug 19 14:15:29 ethel avahi-daemon[1042]: Joining mDNS multicast group on in....
Aug 19 14:15:29 ethel a...

[Juhani Simola (ojs)]

I am having the same problem on 16.04, non-virtualized.

For me the problem started when I switched from a motherboard with Realtek RTL8111H to one with Intel I219-V. There were no other hardware changes at the time and only regular software upgrades from Ubuntu.

[Markus Ketterl (markus-ketterl)]

I have the problem too. After the dhcp lease is expired the avahi-daemon or something else doesn't renew the dhcp lease. It helps to request an ip address manually:

# sudo dhclient <network interface>
sudo dhclient enp3s0

Configure the lease time on your dhcp server to 86400 seconds (one day) and it should help the most of us to work without problems for a day. But it doesn't solve the problem.

[Graham Bosworth (graham-bozikins)]

The failure had not recurred until today. My slightly amended version of the script provided above by Steve Chadsey (schadsey), 2017-07-19, https://bugs.launchpad.net/ubuntu/+source/avahi/+bug/1586528/comments/18 did not rectify the problem. I have since modified it more and hope that it can provide useful diagnostics next time there is a similar failure.

The connection was active until after 00:49:01. It was restored manually by 08:11:59. Unfortunately, I cannot be certain whether I reactivated the interface or whether an automated script did so.

yoyo ~ # ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:25:64:72:72:14
          inet6 addr: fe80::c1e6:4b25:5c64:f669/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
          RX packets:65340342 errors:0 dropped:0 overruns:0 frame:0
          TX packets:26833432 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:21650436815 (21.6 GB) TX bytes:140523812727 (140.5 GB)
          Interrupt:18

yoyo ~ # ifconfig eth0 down
yoyo ~ # ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:25:64:72:72:14
          BROADCAST MULTICAST MTU:1500 Metric:1
          RX packets:65340378 errors:0 dropped:0 overruns:0 frame:0
---------------------^^^^^^^^------------------^
          TX packets:26833625 errors:0 dropped:0 overruns:0 carrier:0
---------------------^^^^^^^^------------------^
          collisions:0 txqueuelen:1000
          RX bytes:21650441164 (21.6 GB) TX bytes:140523828704 (140.5 GB)
-------------------^^^^^^^^^^^---------------------^^^^^^^^^^^^
          Interrupt:18

Notice that the counts of packets and bytes had been increasing, and that no packets had been dropped.

yoyo ~ # ip a add 192.168.42.187 dev eth0

yoyo ~ # ip a s eth0
2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state DOWN group
default qlen 1000
    link/ether 00:25:64:72:72:14 brd ff:ff:ff:ff:ff:ff
    inet 192.168.42.187/32 scope global eth0
       valid_lft forever preferred_lft forever

yoyo ~ # ip a del 192.168.42.187 dev eth0
Warning: Executing wildcard deletion to stay compatible with old scripts.
         Explicitly specify the prefix length (192.168.42.187/32) to avoid
 this warning.
         This special behaviour is likely to disappear in further releases,
         fix your scripts!

yoyo ~ # ip a s eth0
2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state DOWN group
default qlen 1000
    link/ether 00:25:64:72:72:14 brd ff:ff:ff:ff:ff:ff

yoyo ~ # ip a add 192.168.42.187/24 dev eth0

yoyo ~ # ip a s eth0
2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state DOWN group
default qlen 1000
    link/ether 00:25:64:72:72:14 brd ff:ff:ff:ff:ff:ff
    inet 192.168.42.187/24 scope global eth0
       valid_lft forever preferred_lft forever

yoyo ~ # ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:25:64:72:72:14
          inet addr:192.168.42.187 Bcast:0.0.0.0 Mask:255.255.255.0yoyo ~ # ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:25:64:72:72:14
          inet addr:192.168.42.187 Bcast:0.0.0.0 Mask:255.255.255.0
          BROADCAST MULTICAST MTU:1500 Metric:1
          RX pack...

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Alexander Karlstad (alexander.karlstad)]

This has been happening to me lately. I am using 17.04.

I have a feeling it might be IPv6 related since we just started using that at work, so it's only affecting me there. Usually I see the following in my syslog:

> Sep 5 15:40:46 laptop avahi-daemon[1158]: Withdrawing address record for 1234:5678:4556::99 on eth0.
> Sep 5 15:40:46 laptop avahi-daemon[1158]: Leaving mDNS multicast group on interface eth0.IPv6 with address 1234:5678:4556::99.

[Tomsa Liviu (l2s)]

Exact same issue. Ubuntu 16.04 LTS 64 (latest updates).
Evert 2-3 days this box is offline? Why? Any fix for this? Ty.
Can be DDoS or random disconnects from avahi, IPV6 or from other scripts?

-- syslog from Sep 16
Sep 16 08:55:59 ?????? kernel: [??????] [UFW BLOCK] IN=enp5s0 OUT= MAC=?????? SRC=42.51.32.198 DST=?????? LEN=44 TOS=0x08 PREC=0x00 TTL=99 ID=256 PROTO=TCP SPT=6000 DPT=3306 WINDOW=16384 RES=0x00 SYN URGP=0
Sep 16 09:09:17 ?????? avahi-daemon[818]: Withdrawing address record for ?????? on enp5s0.
Sep 16 09:09:17 ?????? avahi-daemon[818]: Leaving mDNS multicast group on interface enp5s0.IPv4 with address ??????.
Sep 16 09:09:17 ?????? avahi-daemon[818]: Interface enp5s0.IPv4 no longer relevant for mDNS.
Sep 16 09:09:37 ?????? whoopsie[1213]: [09:09:37] Cannot reach: https://daisy.ubuntu.com
Sep 16 09:09:37 ?????? whoopsie[1213]: [09:09:37] offline

[Fred Sanderson (fredsandy)]

I'm having the issue on an AWS VM, which would be based of their customized Xen hypervisor.

An AWS engineer replied with the following:
The private IP being released (at-least appears in messages) [is not the case], we checked the DHCP server of the instance to see if the DHCP client of the instance is sending the DHCPRequest or not. Based on the investigation and logs, I can confirm that the DHCP client of the instance i-###############3 is requesting the private IP 172.xxx.xxx.xxx of the instance via DHCPRequest and get the renewal successfully via DHCPAck. Having said that, it appears that the IP address is not being removed, it just that avahi detected that the IP address has been removed, and is changing its internal state in response and we need to look further.

[Graham Bosworth (graham-bozikins)]

It's been a while, but the interface does not fail when I want it to. My script has been enhanced with more diagnostics, which have not given any answers. I have seen that iptables is empty, so I think that D.H.C.P. or U.D.P. is not hitting a DROP.

But here's something that strikes me as very odd - I now have three network interfaces on the computer, for the purposes of testing, but only the wired one, eth0, was active and enabled. The address was lost again as usual, but manually starting "dhclient" on ANOTHER interface brought "eth0" back up with the address that had previously been associated with a wireless interface.

There is a bit of a history attached. Now I am waiting for the network to be lost again to see what else I can learn.

[Graham Bosworth (graham-bozikins)]

Here we go again. This time, the script revealed nothing that looked interesting. Here are some extracts from logs:-

2017-09-28T02:52:32+0100 ifconfig
==================================
eth0 Link encap:Ethernet HWaddr 00:25:64:72:72:14
          inet6 addr: fe80::c1e6:4b25:5c64:f669/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
          RX packets:7627566 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2808062 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:2606664279 (2.6 GB) TX bytes:18724680986 (18.7 GB)
          Interrupt:18
...
2017-09-28T02:52:32+0100 ls -lA /var/run/dhclient*
==================================================
-rw-r--r-- 1 root root 6 Sep 28 02:47 /var/run/dhclient-eth0.pid
-rw-r--r-- 1 root root 6 Sep 27 14:28 /var/run/dhclient.pid
----------------
2017-09-28T02:52:32+0100 ps aux | grep -v grep | grep dhc
=========================================================
root 30610 0.0 0.0 16128 1540 ? S Sep27 0:00 /sbin/dhclient -d -q -sf /usr/lib/NetworkManager/nm-dhcp-helper -pf /var/run/dhclient-eth0.pid -lf /var/lib/NetworkManager/dhclient-3339a4b3-ef0a-3db1-acf1-9b810d040dfe-eth0.lease -cf /var/lib/NetworkManager/dhclient-eth0.conf eth0
----------------

Attempting to wake inactive interfaces (which had seemed to work previously) did not revive a connection, but there was success when trying to revive the interface that should have been active (although it was not the expected address), then another restart brought things back to the norm:-

[LinuxMint] graham@yoyo $ TestNet.sh
Starting /home/graham/bin/TestNet.sh, version : 0.9 $.
No default route has been detected.
Our I.P. address :
Finished /home/graham/bin/TestNet.sh.
Thu Sep 28 03:18:14 ~
[LinuxMint] graham@yoyo $ export ifc="eth0" ; sudo ifconfig -v ${ifc} down ; sleep 3 ; sudo ifconfig -v ${ifc} up ; sleep 2 ; sudo /sbin/dhclient -v ${ifc} ; ifconfig ${ifc}
Internet Systems Consortium DHCP Client 4.3.3
Copyright 2004-2015 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/eth0/00:25:64:72:72:14
Sending on LPF/eth0/00:25:64:72:72:14
Sending on Socket/fallback
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 3 (xid=0x6719e377)
DHCPREQUEST of 192.168.42.224 on eth0 to 255.255.255.255 port 67 (xid=0x77e31967)
DHCPOFFER of 192.168.42.224 from 192.168.42.129
DHCPACK of 192.168.42.224 from 192.168.42.129
bound to 192.168.42.224 -- renewal in 741 seconds.
eth0 Link encap:Ethernet HWaddr 00:25:64:72:72:14
          inet addr:192.168.42.224 Bcast:192.168.42.255 Mask:255.255.255.128
          UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
          RX packets:7629942 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2812141 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:2606838298 (2.6 GB) TX bytes:18725038253 (18.7 GB)
          Interrupt:18

Thu Sep 28 03:19:14 ~
[LinuxMint] graham@yoyo $ TestNet.sh
Starting /home/graham/bin/TestNet.sh, version : 0.9 $.
Our I.P. address : 192.168....

[Nir Yeffet (nir-launchpad-net-8ff8)]

This is probably a bug with Network Manager. I was able to stop the behavior by deleting the connection from the GUI menu (Ubuntu 17.04) and creating new one.

Quick how to: from the network icon-> edit connections... "Network Connections" appears -> choose the one with the problem -> edit -> keep a note with your parameters in all tabs -> Cancel. From "Network Connections" -> choose the one with the problem -> delete -> confirm. (delete also redundant connections) From "Network Connections" -> Add -> choose type -> create... -> set the parameters noted above.

[Graham Bosworth (graham-bozikins)]

Hello Nir,

A few things have been suggested as possibly being at fault, and this has been a long saga, but one of the symptoms is that the "Network Manager" icon can be lost, making it difficult to recover the connection that way. For myself, I want to know either how to prevent the problem from happening, or to find an automated scripted method of recovering after the problem. Have you any suggestions please?

Thanks,
Graham

[Nir Yeffet (nir-launchpad-net-8ff8)]

Graham,

Unfortunately I'm not an expert with Network Manager, until now it remains a mystery to me how it works, where is the configuration stored and where there heck are the log files?!?. Nevertheless, if the "Network Manager" icon disappeared, you can run that "Network Connections" tool directly from "search your computer" (click on the ubuntu logo on the top left or press the "windows" key) and type "Network Connections". Alternatively you can run nm-connection-editor from the terminal. On ubuntu, it is part of package network-manager-gnome.

Nir

[SamTzu (sami-mattila)]

As niedzielski wrote on 2017-07-19:

It's clearly a IPv6 issue. Temp solution is to disable IPv6 until they can fix NetworkManager. Most of us don't need it anyway.

Add the following /etc/sysctl.conf:

  net.ipv6.conf.all.disable_ipv6 = 1
  net.ipv6.conf.default.disable_ipv6 = 1
  net.ipv6.conf.lo.disable_ipv6 = 1

Sam

[Graham Bosworth (graham-bozikins)]

Due to a lack of failures it has been a while since I last wrote, but I think I may have found a possible cause of the problem. Confirmation from other sources would be necessary, of course.

For the previous participants, and anyone else who lands here, I think that the failure may go like this:-

- a network problem prevents reception of a D.H.C.P. lease offer from the server
- NetworkManager starts a new D.H.C.P. client thread, but the old thread is still active and the lease has not expired
- these two steps may be repeated several times, starting several D.H.C.P. threads, with identical or different addresses, possibly receiving and transmitting traffic
- some time (possibly hours) later, another instance of the client has leased the address, the original client's lease expires
- avahi surrenders the address; the host has lost its network connection

In my case, some months earlier, it became apparent that the D.H.C.P. server was connected to a network switch port that was occasionally dropping packets - hence errors were reported for the server's and client's network adaptors. The packet retry count and network load increased. I changed the physical network arrangement and there were no more failures - until I switched off the server for maintenance.

Here is a test which might support this theory. Note that the server was not available between 05:38 and 07:17 on 2018-01-24. The client's network connection was not lost until 2018-01-30.

[LinuxMint] graham@yoyo $ ps -ef | grep -v "grep" | grep -e "PID" -e "dhc"
UID PID PPID C STIME TTY TIME CMD
root 2444 1 0 Jan24 ? 00:00:00 /sbin/dhclient -v eth0
root 3327 1 0 Jan24 ? 00:00:00 /sbin/dhclient -v eth0
root 4550 1 0 Jan24 ? 00:00:00 /sbin/dhclient -v eth0
root 5070 1 0 Jan24 ? 00:00:00 /sbin/dhclient -v eth0
root 6094 1 0 Jan24 ? 00:00:00 /sbin/dhclient -v eth0
root 6616 1 0 Jan24 ? 00:00:00 /sbin/dhclient -v eth0
root 7605 1 0 Jan24 ? 00:00:00 /sbin/dhclient -v eth0
root 8179 1 0 Jan24 ? 00:00:00 /sbin/dhclient -v eth0
root 9152 1 0 Jan24 ? 00:00:00 /sbin/dhclient -v eth0
root 9442 1 0 Jan24 ? 00:00:00 /sbin/dhclient -v eth0
root 21279 11291 0 03:26 ? 00:00:00 /sbin/dhclient -d -q -sf /usr/lib/NetworkManager/nm-dhcp-helper -pf /var/run/dhclient-eth0.pid -lf /var/lib/NetworkManager/dhclient-3339a4b3-ef0a-3db1-acf1-9b810d040dfe-eth0.lease -cf /var/lib/NetworkManager/dhclient-eth0.conf eth0
Tue Jan 30 08:38:33 ~

The start times of those dhclient instances were:- 05:50 05:55 06:05 06:11 06:21 06:27 06:37 06:43 06:53 06:59.

The log server had many instances of exchanges between kevin the server and yoyo the client like this:-
2018-01-30T07:25:11+00:00 kevin dhcpd[3612]: DHCPREQUEST for 192.168.42.187 from 00:25:64:72:72:14 via enp0s19
2018-01-30T07:25:11+00:00 kevin dhcpd[3612]: DHCPACK on 192.168.42.187 to 00:25:64:72:72:14 via enp0s19
2018-01-30T07:25:17+00:00 yoyo dhclient[2444]: DHCPREQUEST of 192.168.42.161 on eth0 to 192.168.42.129 port 67 (xid=0x182b3059)
2018-01-30T07:25:17+00:00 k...

[Graham Bosworth (graham-bozikins)]

This is an update to my previous post, correcting an error of mine - I think that the extra "dhclient" threads were created by the script that was meant to be diagnosing the fault, not by NetworkManager. Consequently, some of the reasoning was not valid. However, it may still be true that physical network errors are contributing to the problem. I shall wait and see what happens.

[Sander van der Stap (sandrovski)]

Same problem with raspbian stretch and avahi.

I used dhcp binding of my router to fix the address 192.168.2.4 to Mac address b8:27:eb:3f:11:5f.

Few hours later, after the syslog gives the "Withdrawing address record for 192.168.2.4" the machine gets another ip-adres, 192.168.2.23 from the dhcp router.

Checking in the router to see why it don't bind I see the router assigns 192.168.2.23 to Mac address 86:16:f9:3f:11:5f

The first Mac address is right, b8:27:eb belongs to raspberry http://standards-oui.ieee.org/oui.txt
The second Mac address starting 86:16:f9 is not known by http://standards-oui.ieee.org/oui.txt.

Where does the second, incorrect, Mac address came from?

[deadite66 (deadite.66)]

for me this is happening every sunday at the same time, really annoying.

[Philipp Hahn (pmhahn)]

I'm running Debian-Stretch 9.4 and I'm observing a similar problem that after some time my servers disappears from the network; usually first the IPv6 address, the usually some time later the IPv4 address, but not always.

All computers are connected to my FritzBox 7420:
- for IPv4 I'm using the fixed address 192.168.xxx.33/24, which the FritzBox always assigns only to that host.
- for IPv6 I get a daily changing IPv6 address from my internet provider each night, which gets propagated by RA.

The affected host is using systemd 232-25+deb9u2 and I have configured systemd-networkd to do the network configuration:

/etc/systemd/network/40-dhcp.network
 DHCP=ipv4
 IPv6AcceptRA=yes

For now I have disabled DHCP for ipv4 and switched to a static configuration, as it sometimes happens that the network is flacky and does not receive an address during boot at all.

I once compiled my own version of systems with this patch included:
 <https://github.com/systemd/systemd/pull/6918/commits/7f676aa324cb5498a5f9caaaa3d51ecfe53242e0>
It is for <https://github.com/systemd/systemd/issues/5625>.

While I had that custom version running I did *not* observe those issues, but then Debian shipped a security update and since than the problem is back.
This might not be the same issue as there have been different comments in this issue mentioning ifupdown, NetworkManager, ..., but perhaps affected users should clarify their environment, e.g. IPv4 and/or IPv6, static addresses or changing addresses/prefixes, ...

[ronny (ronny-standtke)]

I think I found the culprit:
https://bugs.isc.org/Public/Bug/Display.html?id=45540

It boils down to a bug in the isc-dhcp-client. It doesn't correctly react to time synchronization events and therefore simply breaks in situations where time jumps "backwards" and the lease time in the network is relatively short.

In my case I "fixed" the bug by removing the package isc-dhcp-client. The NetworkManager now uses its internal dhcp client which doesn't support as much features but at least works in my situations without breaking the network connection.

[Trent Lloyd (lathiat)]

Thanks for the note ronny, that is a really helpful note. That may well be the cause for many of these cases.

[Deepa (dpaclt)]

Is there any fix for this

[ghomem (gustavo)]

This is happening on 16.0.4 LTS with ethernet connected PCs. Relevant logs:

May 15 00:58:28 shuttle01 dhclient[1203]: DHCPREQUEST of 192.168.1.89 on enp2s0 to 192.168.1.3 port 67 (xid=0x218cacc0)
May 15 00:58:28 shuttle01 dhclient[1203]: DHCPACK of 192.168.1.89 from 192.168.1.3
May 15 00:58:28 shuttle01 dhclient[1203]: bound to 192.168.1.89 -- renewal in 29125 seconds.
May 15 01:17:01 shuttle01 CRON[24411]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
May 15 01:39:44 shuttle01 avahi-daemon[893]: Withdrawing address record for 192.168.1.89 on enp2s0.
May 15 01:39:44 shuttle01 avahi-daemon[893]: Leaving mDNS multicast group on interface enp2s0.IPv4 with address 192.168.1.89.
May 15 01:39:44 shuttle01 avahi-daemon[893]: Interface enp2s0.IPv4 no longer relevant for mDNS.
May 15 01:39:44 shuttle01 whoopsie[1467]: [01:39:44] Cannot reach: https://daisy.ubuntu.com
May 15 01:39:44 shuttle01 whoopsie[1467]: [01:39:44] offline

[hellscream (weisswilly1985)]

I found a workaround this problem.
Check my git
https://github.com/WillyWeiss/-Avahi-daemon-withdraws-address-record-/blob/master/README.md

I just a simple bash that check for a valid IP Address on a given card.
If the IP is not found then 'dhclient' will be called on that given interface(card)
It is working by default on eth0 but you can add more cards in the script. Just read the readme in the git above.

Hope it helps.

Prove of functionality:
Sep 24 16:47:40 MyHostName rngd[395]: stats: Entropy starvations: 0
Sep 24 16:47:40 MyHostName rngd[395]: stats: Time spent starving for entropy: (min=0; avg=0.000; max=0)us
Sep 24 16:47:46 MyHostName avahi-daemon[380]: Withdrawing address record for 192.168.0.13 on eth0.
Sep 24 16:47:46 MyHostName avahi-daemon[380]: Leaving mDNS multicast group on interface eth0.IPv4 with address 192.168.0.13.
Sep 24 16:47:46 MyHostName avahi-daemon[380]: Interface eth0.IPv4 no longer relevant for mDNS.
Sep 24 16:47:47 MyHostName dhclient[4487]: DHCPREQUEST for 192.168.0.13 on eth0 to 255.255.255.255 port 67
Sep 24 16:47:47 MyHostName dhclient[4487]: DHCPACK of 192.168.0.13 from 192.168.0.1
Sep 24 16:47:47 MyHostName avahi-daemon[380]: Joining mDNS multicast group on interface eth0.IPv4 with address 192.168.0.13.
Sep 24 16:47:47 MyHostName avahi-daemon[380]: New relevant interface eth0.IPv4 for mDNS.
Sep 24 16:47:47 MyHostName avahi-daemon[380]: Registering new address record for 192.168.0.13 on eth0.IPv4.
Sep 24 16:47:47 MyHostName dhclient[4487]: bound to 192.168.0.13 -- renewal in 41664 seconds.

[Ilya Brik (ibrik)]

I wonder how do you , guys, declare the bug as invalid while the issue is exists and it's still relevant.
You could at least call it duplicate with a reference to another issue, but INVALID it is not.
To the point:
This issue is relevant for me on a freshly installed Kubuntu 19.04.
I tried to use the workaround proposed by @ronny, but it doesn't look as a good idea:

sudo apt remove isc-dhcp-client Sun 13 Oct 2019 13:45:45 IDT
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages were automatically installed and are no longer required:
  dns-root-data dnsmasq-base isc-dhcp-common libdns-export1104 libisc-export1100 libkf5modemmanagerqt6 libndp0 libopenconnect5 libstoken1 libteamdctl0 libtomcrypt1 libtommath1 libtss2-esys0 libtss2-udev pptp-linux
Use 'sudo apt autoremove' to remove them.
The following packages will be REMOVED:
  isc-dhcp-client network-manager network-manager-gnome network-manager-pptp network-manager-pptp-gnome plasma-nm ubuntu-minimal

[Trent Lloyd (lathiat)]

The bug was marked invalid for *Avahi* but Confirmed for network-manager -- because the bug exists not in Avahi (it simply logs the message you see as a result of the IP address being removed). So the bug is still valid and confirmed, just for network-manager instead.

[Ciprian Radu (ciprianradu)]

I am experiencing this problem from a Raspberry Pi 4, running Raspbian. It seems that disabling IPv6 works. I also removed isc-dhcp-client but it did not solve the problem.

[Christoph Duwald (ichbaum)]

I had the same problem on an Raspberry Pi4 4GB.
Uninstalling the avahi-deamon wokrs just fine. Even if this may not the cause of the problem, my Pi is running for the last 12 days without a problem.

 avahi-daemon[350]: Withdrawing address record for 192.168.1.116 on eth0.
 avahi-daemon[350]: Leaving mDNS multicast group on interface eth0.IPv4 with address 192.168.1.116.
 avahi-daemon[350]: Interface eth0.IPv4 no longer relevant for mDNS.

[Phill Kelley (paraphraser)]

I am also seeing this same problem on a Raspberry Pi4 4GB.

I purchased the Pi last November and installed from the then-available 2019-09-26-raspbian-buster.zip but routinely keep it updated (apt update / apt upgrade).

The Pi was rock solid and did not exhibit any problems until 2020-02-24 when I applied some updates followed by a "sudo reboot" but the boot process did not complete. The Pi runs headless so I don't know whether it never actually completed the shutdown, or failed to reboot. I power-cycled the device and it came back OK.

Another set of updates were applied on 2020-03-11 and the subsequent reboot completed without incident so I assumed the earlier problem was a one-off.

Then, on 2020-03-14 the Pi froze. Wouldn't respond to pings, ssh or vnc. It is Ethernet-connected but the WiFi interface is active and it did not occur to me to try connecting via WiFi. I just did another power-cycle and then started nosing around through the logs. Which brought me to:

Mar 14 12:48:16 iot-hub avahi-daemon[361]: Withdrawing address record for 192.168.132.60 on eth0.
Mar 14 12:48:16 iot-hub avahi-daemon[361]: Leaving mDNS multicast group on interface eth0.IPv4 with address 192.168.132.60.
Mar 14 12:48:16 iot-hub avahi-daemon[361]: Interface eth0.IPv4 no longer relevant for mDNS.

and, from there, to this post.

The main reasons I'm adding a comment to this post are (a) as a "me too" as of March 2020, and (b) in case the pattern of the RPi being perfectly OK until 2020-02-24 causes someone to say "ahah!"

The updates in question were (from the history log): Upgrade: libpython3.7-minimal:armhf (3.7.3-2, 3.7.3-2+deb10u1), libraspberrypi-bin:armhf (1.20200114-1, 1.20200212-1), libopenjp2-7:armhf (2.3.0-2, 2.3.0-2+deb10u1), rc-gui:armhf (1.34, 1.36), libcom-err2:armhf (1.44.5-1+deb10u2, 1.44.5-1+deb10u3), libcups2:armhf (2.2.10-6+deb10u1, 2.2.10-6+deb10u2), libraspberrypi-dev:armhf (1.20200114-1, 1.20200212-1), libraspberrypi-doc:armhf (1.20200114-1, 1.20200212-1), python3.7-venv:armhf (3.7.3-2, 3.7.3-2+deb10u1), raspberrypi-ui-mods:armhf (1.20200127, 1.20200218), qt5-gtk-platformtheme:armhf (5.11.3+dfsg1-1+rpi1, 5.11.3+dfsg1-1+rpi1+deb10u3), libfm4:armhf (1.3.1-1+rpt12, 1.3.1-1+rpt13), libsystemd0:armhf (241-7~deb10u2+rpi1, 241-7~deb10u3+rpi1), raspi-config:armhf (20200205, 20200207), libfm-modules:armhf (1.3.1-1+rpt12, 1.3.1-1+rpt13), libfm-extra4:armhf (1.3.1-1+rpt12, 1.3.1-1+rpt13), mariadb-common:armhf (1:10.3.17-0+deb10u1, 1:10.3.22-0+deb10u1), binutils:armhf (2.31.1-16+rpi1, 2.31.1-16+rpi2), e2fsprogs:armhf (1.44.5-1+deb10u2, 1.44.5-1+deb10u3), sudo:armhf (1.8.27-1+deb10u1, 1.8.27-1+deb10u2), libqt5dbus5:armhf (5.11.3+dfsg1-1+rpi1, 5.11.3+dfsg1-1+rpi1+deb10u3), libqt5sql5-sqlite:armhf (5.11.3+dfsg1-1+rpi1, 5.11.3+dfsg1-1+rpi1+deb10u3), python3-pil:armhf (5.4.1-2, 5.4.1-2+deb10u1), libpython3.7:armhf (3.7.3-2, 3.7.3-2+deb10u1), python3.7:armhf (3.7.3-2, 3.7.3-2+deb10u1), openssh-sftp-server:armhf (1:7.9p1-10+deb10u1, 1:7.9p1-10+deb10u2), libqt5widgets5:armhf (5.11.3+dfsg1-1+rpi1, 5.11.3+dfsg1-1+rpi1+deb10u3), libfm-gtk4:armhf (1.3.1-1+rpt12, 1.3.1-1+rpt13), udev:armhf (241-7~deb10u2+rpi1, 241-7~deb10u3+rpi1), python3.7-dev:armhf (3.7.3-2, 3.7....

[ttbek (ttbek)]

Are you guys sure it isn't Avahi? It was still happening to me after stopping the network manager service. Is it not the incompatibility mentioned in the Arch docs? https://wiki.archlinux.org/index.php/Avahi My ip and dns finally stopped changing when I disabled Avahi. Also happened to this guy: https://jrs-s.net/2015/01/09/avahi-killed-my-server/ I have a similar bridge setup to his. Maybe my case (and that guy's) is a different bug/issue though.

[Juan Martinez (cubislo)]

Same issue - Dell Precision 7040

Oct 14 20:20:17 ubuntu-Wyse-7040 avahi-daemon[1363]: Withdrawing address record for 192.168.1.121 on enp0s31f6.
Oct 14 20:20:17 ubuntu-Wyse-7040 avahi-daemon[1363]: Leaving mDNS multicast group on interface enp0s31f6.IPv4 with address 192.168.1.121.
Oct 14 20:20:17 ubuntu-Wyse-7040 avahi-daemon[1363]: Interface enp0s31f6.IPv4 no longer relevant for mDNS.

This happens both with DHCP and Static IP. Nothing of note appears to precede these log messages. kern.log does not have any relevant logs.

Behavior is a dropped network every ~1.5 days. Did not have this problem with wifi, only when hardwired. Runs with no displays attached.

Currently Ubuntu 19.10 - will be upgrading to 20.04 and will update if issue does not resolve

[Jack (jack-234521)]

weisswilly1985 THANK YOU - your workaround is a lifesaver on my rpi4, Raspberry Pi OS (stock kernel).

Here's my tested script to get it installed locally:

# add a workaround script to rememdy eth0 losing it's IP lease randomly
wget https://raw.githubusercontent.com/WillyWeiss/Avahi-daemon-withdraws-address-record-/master/isc-dhcp-fix.sh
sudo mv isc-dhcp-fix.sh /usr/bin/isc-dhcp-fix.sh
sudo chmod +x /usr/bin/isc-dhcp-fix.sh
sudo chown root:root /usr/bin/isc-dhcp-fix.sh
sudo nano /etc/rc.local
# add this line just above the final 'exit 0' line
/usr/bin/isc-dhcp-fix.sh &
# run it without a reboot to check for errors, then reboot
bash /usr/bin/isc-dhcp-fix.sh &
sudo reboot now

and here it is in action in the daemon.log file -

Nov 2 20:51:34 raspberrypi avahi-daemon[385]: Withdrawing address record for 10.0.1.176 on eth0.
Nov 2 20:51:34 raspberrypi avahi-daemon[385]: Leaving mDNS multicast group on interface eth0.IPv4 with address 10.0.1.176.
Nov 2 20:51:34 raspberrypi avahi-daemon[385]: Interface eth0.IPv4 no longer relevant for mDNS.
Nov 2 20:51:34 raspberrypi dhclient[14510]: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 3
Nov 2 20:51:34 raspberrypi dhclient[14510]: DHCPOFFER of 10.0.1.176 from 10.0.1.1
Nov 2 20:51:34 raspberrypi dhclient[14510]: DHCPREQUEST for 10.0.1.176 on eth0 to 255.255.255.255 port 67
Nov 2 20:51:34 raspberrypi dhclient[14510]: DHCPACK of 10.0.1.176 from 10.0.1.1

[Claudio Kuenzler (napsty)]

I've just seen this issue the first time on a Ubuntu 20.04 (updated several months ago from 16.04) AWS EC2 machine. Looking closer into this, the machine lost its IP address multiple times in the last hours. The following avahi-daemon log messages made me find this bug report:

ck@focal:~$ grep avahi-daemon /var/log/syslog | grep -i withdrawing
Jan 18 20:17:42 inf-mon04-p avahi-daemon[941]: Withdrawing address record for 10.10.1.41 on eth0.
Jan 18 21:44:52 inf-mon04-p avahi-daemon[941]: Withdrawing address record for 10.10.1.41 on eth0.

It's very interesting, that both of these events happened EXACTLY one hour after the system boot:

ck@focal:~$ last | head
ck pts/0 xx.xx.xx.xxx Tue Jan 18 22:11 still logged in
root ttyS0 Tue Jan 18 21:50 still logged in
reboot system boot 5.4.0-91-generic Tue Jan 18 20:44 still running
reboot system boot 5.4.0-91-generic Tue Jan 18 19:17 - 20:39 (01:22)

Running "dhclient" on the EC2 console, as suggested in comment #46, re-assigns the IP address.

Relevant versions installed:

ck@focal:~$ dpkg -l|egrep "(dhcp|network-manager)"
ii isc-dhcp-client 4.4.1-2.1ubuntu5.20.04.2 amd64 DHCP client for automatically obtaining an IP address
ii isc-dhcp-common 4.4.1-2.1ubuntu5.20.04.2 amd64 common manpages relevant to all of the isc-dhcp packages
ii network-manager 1.22.10-1ubuntu2.2 amd64 network management framework (daemon and userspace tools)
ii network-manager-gnome 1.8.24-1ubuntu3 amd64 network management framework (GNOME frontend)
ii network-manager-pptp 1.2.8-2 amd64 network management framework (PPTP plugin core)

Update: In my situation it turned out to be a problem of networking.service, which was able to request the IP address, however the service failed due to a missing sub-script (ubuntu-fan):

$ systemctl status networking.service
● networking.service - Raise network interfaces
     Loaded: loaded (/lib/systemd/system/networking.service; enabled; vendor preset: enabled)
     Active: failed (Result: exit-code) since Wed 2022-01-19 07:40:25 CET; 4min 55s ago
       Docs: man:interfaces(5)
    Process: 639 ExecStart=/sbin/ifup -a --read-environment (code=exited, status=1/FAILURE)
   Main PID: 639 (code=exited, status=1/FAILURE)

Jan 19 07:40:25 focal dhclient[814]: DHCPACK of 10.10.1.41 from 10.10.1.1 (xid=0xac4f3a09)
Jan 19 07:40:25 focal ifup[828]: RTNETLINK answers: File exists
Jan 19 07:40:25 focal dhclient[814]: bound to 10.10.1.41 -- renewal in 1442 seconds.
Jan 19 07:40:25 focal ifup[814]: bound to 10.10.1.41 -- renewal in 1442 seconds.
Jan 19 07:40:25 focal ifup[870]: /etc/network/if-up.d/ubuntu-fan: 29: /usr/sbin/fanctl: not found
Jan 19 07:40:25 focal ifup[840]: run-parts: /etc/network/if-up.d/ubuntu-fan exited with return code 127
Jan 19 07:40:25 focal ifup[639]: ifup: failed to bring up eth0
Jan 19 07:40:25 focal systemd[1]: networking.service: Main process exited, code=exited, status=1/FAILURE
Jan 19 07:40:25 f...

[Ashish upara (ashishepsilon)]

Is this issue solved till now?
Also are these solutions applicable for Ubuntu 20.04.6 LTS or not.

[Graham Bosworth (graham-bozikins)]

On Thu, 28 Mar 2024, Ashish upara wrote:

> Date: Thu, 28 Mar 2024 13:24:55
> From: Ashish upara <email address hidden>
> To: <email address hidden>
> Subject: [Bug 1586528] Re: Avahi-daemon withdraws address record
>
> Is this issue solved till now?
> Also are these solutions applicable for Ubuntu 20.04.6 LTS or not.
>
>
Hello,

  I am sorry that I had not noticed your question earlier.

  It would be better if you sent your question to the "Launchpad"
  discussion, where there are many more people who have much more knowledge
  than I have.

  Yours,
--
Graham
"What's the difference between a 'hippo' and a 'Zippo'? One is really heavy, the other is a little lighter" -- Masai Graham

<a href="http://english-1329209197.spampoison.com">Get free spam bait here.</a>