Bug#764084: ifplugd & NetworkManager

[Bengt Bjorkberg]

Not certain if this bug is still open. Or if this is even the right way to 
raise an issue. 
Been looking at this bug quite a few times, and ended up raising a new bug 
(810184). 

I am not certain if this bug is open or closed (sorry for my ignorance), but 
there seems to be three different issues. 
1. avahi fails to pick up (or take into account) all interfaces
2. there seems to be no way to force it to take additional interfaces into 
account 
3. There is a daemon that does not work as expected and fails to stay dead if 
told to do so

There is a simple fix to the issue, just apt-get remove avahi-daemon does the 
trick. May seem extreme, but seems simpler than disabling a interface.

Also, it seemed like the bug is stating that the issue was resolved, and as far 
as I can tell it is not.

Of course, please feel free to close the duplicate.

On Wed, 25 Mar 2015 15:31:31 +0100 Cyrille Bollu  
wrote:
> Ok,
> 
> As I couldn't understand to configure NM to disable this zeroconf/ipv4ll
> stuff (where's the doc?!?), I've tried to use ifplugd.
> 
> It's a neat package, but there are gotcha:
> 
> 1- you need to configure it, because by default it won't monitor any
> interface, despite what's writen in its man page (option -i);
> 2- you need to uninstall avahi-autoipd, as otherwise, it will do its thing
> and you'll end up with a default route to 169.254
> 
> So, in my case, by uninstalling avahi-autoipd and installing and
> configuring ifplugd, I could overcome this issue.
> 
> So, now, I've a nice system that automatically set up my ethernet network
> interface when needed (ie: when there's a cable plugged in), but without
> ipv4ll (RFC3927) support.
> 
> Cyrille

-- 

--
This message is confidential and intended for the use of the addressee only.
If you believe you have received this email in error, then kindly return 
the message to the sender and delete from your computer.
While we scan all our mail for viruses, you should verify the safety of all 
attachments in this email before opening.  Internet communications are not 
guaranteed to be private or secure and DBFS Ltd accepts no responsibility 
for changes made to this message after it was sent.  
*DBFS Ltd, Five Kings House, 1 Queen St Place, London EC4R 1QS, United 
Kingdom.  http://www.dbfs.co.uk *

Bug#764084:

[Cyr Bol]

Hi,

I've the same problem.

And, indeed, my eth0 is configured for DHCP, and it is not connected at
boot when the problem happens.

I'll dig for more information about NetworkManager and ifplugd to fix my
problem, but, do you really think it's working as designed when
avahi-autoipd creates a new default route to an unconnected interface (see
original post - I've the exact same behaviour-)? Because that really is the
problem: When I delete this route, my wireless connectivity works again.

Best regards,

Cyrille

Bug#764084: ifplugd NetworkManager

[Cyrille Bollu]

Ok,

As I couldn't understand to configure NM to disable this zeroconf/ipv4ll
stuff (where's the doc?!?), I've tried to use ifplugd.

It's a neat package, but there are gotcha:

1- you need to configure it, because by default it won't monitor any
interface, despite what's writen in its man page (option -i);
2- you need to uninstall avahi-autoipd, as otherwise, it will do its thing
and you'll end up with a default route to 169.254

So, in my case, by uninstalling avahi-autoipd and installing and
configuring ifplugd, I could overcome this issue.

So, now, I've a nice system that automatically set up my ethernet network
interface when needed (ie: when there's a cable plugged in), but without
ipv4ll (RFC3927) support.

Cyrille

Bug#533233: relates to bug 764084

[Cyrille Bollu]

This bug relates to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=764084

I like the simple solution proposed in message #26 (
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=533233#26) where the
metric for RFC3927 subnet is raised above the wireless connexions' default
metric (1024).

However, a definitive solution would be that avahi-autoipd doesn't assign a
RFC3927 address when no cable is connected to the ethernet interface. Maybe
the ifupdown-extra could help here?

See also bug 764084 for more on this RFC3927 problem.

Cyrille

Bug#764084: avahi-daemon creates eth0:avahi briefly after startup overriding wlan0, no eth0 connected

[Pedro Alvarez]

On Sun, 5 Oct 2014 17:07:26 +0200 
=?UTF-8?B?w4Z2YXIgQXJuZmrDtnLDsCBCamFybWFzb24=?= ava...@gmail.com wrote:


systemctl disable avahi-daemon.service
systemctl disable avahi-daemon.socket


Disabling these 2 was enough to make the bug disappear in my system, but 
worth noting that this is still happening in an up-to-date jessie system.


--
Pedro Alvarez Piedehierro


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#764084: [Pkg-utopia-maintainers] Bug#764084: avahi-daemon creates eth0:avahi briefly after startup overriding wlan0, no eth0 connected

[Michael Biebl]

Am 05.10.2014 um 13:45 schrieb Ævar Arnfjörð Bjarmason:
 Package: avahi-daemon
 Version: 0.6.31-4
 Severity: normal
 Tags: upstream
 
 I don't know if this bug is properly filed under avahi-daemon or
 avahi-autoipd.
 
 When I start up my laptop that's only connected via wlan0 it takes
 about a minute until avahi-autoipd/avahi-daemon creates an eth0:avahi
 interface, and makes that default route. This renders my Internet
 connection useless until I manually remove the route or shut down the
 interface.

I suspect you have eth0 dhcp configuration in your
/etc/network/interfaces configuration? Is that correct? Is this
interfaces connected during boot?

If not, dhclient will timeout, and avahi-autoipd will kick in, assigning
a link local IP address. It basically works as designed.

If so, you should fix your /etc/network/interfaces to use something like
ifplugd, to only activate the interface when the interface is actually
connected, remove the eth0 configuration completely if not needed, or
use a tool like NetworkManager, which deals with that properly.

Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#764084: avahi-daemon creates eth0:avahi briefly after startup overriding wlan0, no eth0 connected

[Vikram Vincent]

Subject: avahi-daemon creates eth0:avahi briefly after startup overriding
wlan0, no eth0 connected
Followup-For: Bug #764084
Package: avahi-daemon
Version: 0.6.31-4+b1

The bug is confirmed on my system as well. I need to manually disable the
eth0:avahi in order to be able to access the internet.  The problem arises
during bootup when the system is trying to raise the network interfaces.
However, creation of the interface is NOT brief as mentioned as it
continues to survive until the system is shutdown. I have attached the
screenshot of the htop output

-- System Information:
Debian Release: jessie/sid
  APT prefers testing-updates
  APT policy: (500, 'testing-updates'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages avahi-daemon depends on:
ii  adduser  3.113+nmu3
ii  bind9-host [host]1:9.9.5.dfsg-5
ii  dbus 1.8.8-2
ii  host 1:9.9.5.dfsg-5
ii  init-system-helpers  1.21
ii  libavahi-common3 0.6.31-4+b1
ii  libavahi-core7   0.6.31-4+b1
ii  libc62.19-12
ii  libcap2  1:2.24-6
ii  libdaemon0   0.14-6
ii  libdbus-1-3  1.8.8-2
ii  libexpat12.1.0-6+b2
ii  lsb-base 4.1+Debian13+nmu1

Versions of packages avahi-daemon recommends:
pn  libnss-mdns  none

Versions of packages avahi-daemon suggests:
ii  avahi-autoipd  0.6.31-4+b1

-- no debconf information

Bug#764084: avahi-daemon creates eth0:avahi briefly after startup overriding wlan0, no eth0 connected

[Ævar Arnfjörð Bjarmason]

Package: avahi-daemon
Version: 0.6.31-4
Severity: normal
Tags: upstream

I don't know if this bug is properly filed under avahi-daemon or
avahi-autoipd.

When I start up my laptop that's only connected via wlan0 it takes
about a minute until avahi-autoipd/avahi-daemon creates an eth0:avahi
interface, and makes that default route. This renders my Internet
connection useless until I manually remove the route or shut down the
interface.

Before it runs the ifconfig/route output is this (I've removed the
lo interface for brevity):

eth0  Link encap:Ethernet  HWaddr b8:ca:3a:c0:da:4e
  UP BROADCAST MULTICAST  MTU:1500  Metric:1
  RX packets:0 errors:0 dropped:0 overruns:0 frame:0
  TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
  Interrupt:20 Memory:f7e0-f7e2

wlan0 Link encap:Ethernet  HWaddr 84:3a:4b:12:34:58
  inet addr:192.168.0.200  Bcast:192.168.0.255  Mask:255.255.255.0
  inet6 addr: fe80::863a:4bff:fe12:3458/64 Scope:Link
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:568 errors:0 dropped:0 overruns:0 frame:0
  TX packets:493 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:280017 (273.4 KiB)  TX bytes:106784 (104.2 KiB)

Kernel IP routing table
Destination Gateway Genmask Flags Metric RefUse 
Iface
0.0.0.0 192.168.0.1 0.0.0.0 UG1024   00 
wlan0
169.254.0.0 0.0.0.0 255.255.0.0 U 1000   00 
wlan0
192.168.0.0 0.0.0.0 255.255.255.0   U 0  00 
wlan0

And afterwards:

eth0  Link encap:Ethernet  HWaddr b8:ca:3a:c0:da:4e
  UP BROADCAST MULTICAST  MTU:1500  Metric:1
  RX packets:0 errors:0 dropped:0 overruns:0 frame:0
  TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
  Interrupt:20 Memory:f7e0-f7e2

eth0:avahi Link encap:Ethernet  HWaddr b8:ca:3a:c0:da:4e
  inet addr:169.254.9.109  Bcast:169.254.255.255  Mask:255.255.0.0
  UP BROADCAST MULTICAST  MTU:1500  Metric:1
  Interrupt:20 Memory:f7e0-f7e2

wlan0 Link encap:Ethernet  HWaddr 84:3a:4b:12:34:58
  inet addr:192.168.0.200  Bcast:192.168.0.255  Mask:255.255.255.0
  inet6 addr: fe80::863a:4bff:fe12:3458/64 Scope:Link
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:723 errors:0 dropped:0 overruns:0 frame:0
  TX packets:625 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:318197 (310.7 KiB)  TX bytes:127659 (124.6 KiB)
Kernel IP routing table
Destination Gateway Genmask Flags Metric RefUse 
Iface
0.0.0.0 0.0.0.0 0.0.0.0 U 1002   00 eth0
0.0.0.0 192.168.0.1 0.0.0.0 UG1024   00 
wlan0
169.254.0.0 0.0.0.0 255.255.0.0 U 0  00 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 1000   00 
wlan0
192.168.0.0 0.0.0.0 255.255.255.0   U 0  00 
wlan0

This is the full daemon.log as of startup until avahi-daemon creates
the eth0:avahi interface:

Oct  5 13:28:32 snth systemd[1]: Expecting device 
dev-disk-by\x2duuid-f9a53937\x2d6e8b\x2d438f\x2dac10\x2de372ba1c1030.device...
Oct  5 13:28:32 snth systemd[1]: Expecting device 
dev-mapper-sda5_crypt.device...
Oct  5 13:28:32 snth systemd[1]: Starting Device-mapper event daemon FIFOs.
Oct  5 13:28:32 snth systemd[1]: Listening on Device-mapper event daemon 
FIFOs.
Oct  5 13:28:32 snth systemd[1]: Starting LVM2 metadata daemon socket.
Oct  5 13:28:32 snth systemd[1]: Listening on LVM2 metadata daemon socket.
Oct  5 13:28:32 snth systemd[1]: Expecting device 
dev-mapper-snth\x2d\x2dvg\x2dswap_1.device...
Oct  5 13:28:32 snth systemd[1]: Starting File System Check on Root 
Device...
Oct  5 13:28:32 snth systemd[1]: Starting udev Kernel Socket.
Oct  5 13:28:32 snth systemd[1]: Listening on udev Kernel Socket.
Oct  5 13:28:32 snth systemd[1]: Starting udev Control Socket.
Oct  5 13:28:32 snth systemd[1]: Started System Logging Service.
Oct  5 13:28:32 snth avahi-daemon[682]: Found user 'avahi' (UID 103) and 
group 'avahi' (GID 108).
Oct  5 13:28:32 snth avahi-daemon[682]: Successfully dropped root 
privileges.
Oct  5 13:28:32 snth avahi-daemon[682]: avahi-daemon 0.6.31 starting up.
Oct  5 13:28:32 snth systemd[1]: Mounted Arbitrary Executable File Formats 
File System.

Bug#764084: avahi-daemon creates eth0:avahi briefly after startup overriding wlan0, no eth0 connected

[Ævar Arnfjörð Bjarmason]

On Sun, Oct 5, 2014 at 1:45 PM, Ævar Arnfjörð ava...@gmail.com wrote:
 I'm just going to solve this problem my disabling
 avahi-autoipd/avahi-daemon, I don't need a ZeroConf daemon for
 anything, but this seems like really odd and buggy default
 behavior. Why would it be creating an eth0:avahi interface that
 overrides the default wlan0 route?

How does one disable this daemon anyway? This doesn't work:

$ sudo update-rc.d -f avahi-daemon remove
$ sudo update-rc.d avahi-daemon defaults

Neither does setting this in /etc/defaults/avahi-daemon as some
sources I googled suggested: AVAHI_DAEMON_START=0. An old bug report
to this package (#462155) says that's been removed and you should use
this instead:

$ sysv-rc-conf avahi-daemon off

That doesn't work either, it keeps starting up after reboot. It
doesn't work either to set this in avahi-daemon.conf, it creates
eth0:avahi still:

deny-interfaces=eth0,wlan0,tun0

Manually stopping it suggests that it may just be started again
implicitly when something accesses its socket:

$ sudo service avahi-daemon stop
Warning: Stopping avahi-daemon.service, but it can still be
activated by: avahi-daemon.socket

And indeed doing that has no effect, even killing it just brings it
right back up:

== /var/log/daemon.log ==
Oct  5 14:14:54 snth avahi-daemon[3475]: avahi-daemon 0.6.31 exiting.
Oct  5 14:14:54 snth systemd[1]: Stopped Avahi mDNS/DNS-SD Stack.
Oct  5 14:14:54 snth dbus[676]: [system] Activating via systemd:
service name='org.freedesktop.Avahi'
unit='dbus-org.freedesktop.Avahi.service'

So maybe I'm missing something really obvious but if you could tell me
how this service can be stopped that would be much appreciated.


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#764084: avahi-daemon creates eth0:avahi briefly after startup overriding wlan0, no eth0 connected

[Ævar Arnfjörð Bjarmason]

On Sun, Oct 5, 2014 at 2:15 PM, Ævar Arnfjörð Bjarmason
ava...@gmail.com wrote:
 On Sun, Oct 5, 2014 at 1:45 PM, Ævar Arnfjörð ava...@gmail.com wrote:
 I'm just going to solve this problem my disabling
 avahi-autoipd/avahi-daemon, I don't need a ZeroConf daemon for
 anything, but this seems like really odd and buggy default
 behavior. Why would it be creating an eth0:avahi interface that
 overrides the default wlan0 route?

 How does one disable this daemon anyway? This doesn't work:

 $ sudo update-rc.d -f avahi-daemon remove
 $ sudo update-rc.d avahi-daemon defaults

 Neither does setting this in /etc/defaults/avahi-daemon as some
 sources I googled suggested: AVAHI_DAEMON_START=0. An old bug report
 to this package (#462155) says that's been removed and you should use
 this instead:

 $ sysv-rc-conf avahi-daemon off

 That doesn't work either, it keeps starting up after reboot. It
 doesn't work either to set this in avahi-daemon.conf, it creates
 eth0:avahi still:

 deny-interfaces=eth0,wlan0,tun0

 Manually stopping it suggests that it may just be started again
 implicitly when something accesses its socket:

 $ sudo service avahi-daemon stop
 Warning: Stopping avahi-daemon.service, but it can still be
 activated by: avahi-daemon.socket

 And indeed doing that has no effect, even killing it just brings it
 right back up:

 == /var/log/daemon.log ==
 Oct  5 14:14:54 snth avahi-daemon[3475]: avahi-daemon 0.6.31 exiting.
 Oct  5 14:14:54 snth systemd[1]: Stopped Avahi mDNS/DNS-SD Stack.
 Oct  5 14:14:54 snth dbus[676]: [system] Activating via systemd:
 service name='org.freedesktop.Avahi'
 unit='dbus-org.freedesktop.Avahi.service'

 So maybe I'm missing something really obvious but if you could tell me
 how this service can be stopped that would be much appreciated.

Eventually I found that just:

sudo aptitude remove avahi-autoipd

Along with:

systemctl disable avahi-daemon.service
systemctl disable avahi-daemon.socket

And possibly:

systemctl mask avahi-daemon.service
systemctl mask avahi-daemon.socket

That last one might be redundant, or possibly the last two. But I got
tired of exhaustively testing this. So I think this bug report should
be moved to be a gainst the avahi-autoipd package.


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org