Avahi-daemon withdraws address record

Bug #1586528 reported by Matt Schulte on 2016-05-27
134
This bug affects 23 people
Affects Status Importance Assigned to Milestone
avahi (Ubuntu)
High
Unassigned
network-manager (Ubuntu)
High
Unassigned

Bug Description

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)

Matt Schulte (gimpyestrada) wrote :
Trent Lloyd (lathiat) wrote :

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.

Changed in avahi (Ubuntu):
status: New → Invalid
Matt Schulte (gimpyestrada) wrote :

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) wrote :
Download full text (15.6 KiB)

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) wrote :

... 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) wrote :

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) wrote :

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) wrote :

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

Changed in network-manager (Ubuntu):
status: New → Confirmed
Steve Chadsey (schadsey) wrote :

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

Changed in network-manager (Ubuntu):
importance: Undecided → High
Changed in avahi (Ubuntu):
importance: Undecided → High
Iwish (albogdashkin) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

Same problem.
About 1 time per week.

Is there any bug fix or workaround yet?

Trent Lloyd (lathiat) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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

Download full text (16.9 KiB)

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[...

Download full text (7.4 KiB)

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...

Read more...

Juhani Simola (ojs) wrote :

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.

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.

Changed in avahi (Ubuntu):
status: Invalid → New
Download full text (7.4 KiB)

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...

Read more...

Launchpad Janitor (janitor) wrote :

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

Changed in avahi (Ubuntu):
status: New → Confirmed

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) wrote :

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) wrote :

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.

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.

Download full text (5.5 KiB)

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....

Read more...

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.

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

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

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers