avahi-autoipd gives default route to 0.0.0.0

[Victor Noël]

Hi,

I have 2 network interfaces on my computer and i don't use them at the same time, so avahi-autoipd is running on the one not used.
The problem is that it adds a default route with gw as 0.0.0.0.
It could be not important but it confuses openswan when it is started.

[Trent Lloyd (lathiat)]

It is not 'useless' it is installed as a last resort thus should not cause any problems

It what way does it confuse openswan?

[Victor Noël (victornoel)]

When i start openswan, i get this error message :
ipsec_setup: multiple default routes, %defaultroute cannot cope!!!

It is because openswan is looking for the interface that manage the defaultroute, since there is several default route, it fails to start.

And i can't just specify to it an interface in the config file because i don't which one i will be using when i will want to use ipsec.

Can i ask what is the use of this default route ? if there is no interface configured, there is only this default route, will it be used to route traffic ? what is the gateway 0.0.0.0 used for ? has it a special meaning ?

thanks for your help

[Trent Lloyd (lathiat)]

That route tells it to just send packets for any IP directly out the interface, this is usefull because in a LAN using zeroconf LL IPs (as avahi-autoipd), only hosts without another non-LL ip should have an LL ip.

So without a default (last resort) route out the interface, if you only had an LL ip you would not be able to communicate with other hosts that didn't have an LL ip.

[Steve Langasek (vorlon)]

I'm confirming this as a bug. I have never seen a situation where a local-link default route has been useful to me, but I have frequently been bitten by the network timeouts that result from this wrong route. I believe that /etc/avahi/avahi-autoipd.action should be fixed to not set a default route "just in case".

[Trent Lloyd (lathiat)]

Hi Steve,

Anything that is broken by this is inherently broken, not the Avahi setup - and -they- should be fixed.

The link local default is installed at the lowest preference, and should not be used if a better one exists.

The original bug report was about openswan, what specific problems have you had?

Regards,
trent

[Steve Langasek (vorlon)]

On Sun, May 25, 2008 at 11:45:19PM -0000, Trent Lloyd wrote:

> Anything that is broken by this is inherently broken, not the Avahi
> setup - and -they- should be fixed.

Er, no, that's nonsense. Applications that generate network traffic have to
wait for network timeouts as a result of this avahi behavior whenever no
other default route is available - that's not a bug in the application
waiting for network traffic, that's a bug in avahi for asserting that trafic
is routable when it isn't.

The current avahi-autoipd behavior regarding default routes is only
beneficial if:

- the IP you're trying to contact is present on the local link
- your host doesn't have IP routing information configured by some other
  means (e.g., DHCP or static)
- the remote host is configured with a route for link-local addresses
  (Ubuntu with avahi-autoipd is one such implementation, but other
  implementations, particularly older Linux implementations, are not likely
  to be able to answer traffic originating from link-local IPv4 addresses)

This carries with it significant collateral damage: in order to get any
benefit at all from this default route, the system must also endure network
timeouts when trying to connect to any other host that's not on the local
network.

> The link local default is installed at the lowest preference, and should
> not be used if a better one exists.

The problem is precisely that when this route *is* used (because no other
route exists), it directly causes timeout problems.

> The original bug report was about openswan, what specific problems have
> you had?

My specific issue is with the behavior of network-based user authentication
(Kerberos). This behavior will definitely cause problems in other use
cases, however, such as for users of autofs.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

[Loye Young (loyeyoung)]

Steve is right. Setting up a default route on a link-local interface is inherently flawed.

The default route is the the "gateway of last resort", i.e., the router address used when no other known route exists for a given IP packet's destination address. However, the basic architectural assumption of link-local networks is that no routable address is configured. Thus, by definition, no routers or dhcp servers are available to the interface. Consequently, it makes no sense for avahi-autoipd to assign a default route.

Worse, when the host has multiple interfaces, avahi interferes with standards-compliant network connections to the internet. (For example, the host has both a wired NIC connected to routeable network and a wireless card either not connected or connected only to a local printer.) Avahi-autoipd's assignment of a default route will result in multiple default routes (one from it and one from the actual router), causing connectivity to the internet to break. See, e.g., http://ubuntuforums.org/showthread.php?p=4501456 (noting that the best solution is to purge avahi and its cousins).

Happy Trails,

Loye Young
Isaac & Young Computer Company
Laredo, Texas
http://www.iycc.net

[Steve Langasek (vorlon)]

Hi Loye,

Actually, where multiple routes are concerned, Trent is correct; because the avahi default route has a very high metric set, this route will only ever be used by the kernel when there are no other routes available. So if you have another device with a real Internet route, that route should always get precedence over the avahi route.

I do have another anecdote about why this behavior is a problem, though: the other week, my wife was complaining loudly to me on IRC that firefox wasn't working and I should come fix it. I prodded around, found that it wasn't just firefox that was failing, all DNS resolution was failing. But she had gotten connected to IRC, so what had changed to make DNS start failing?

The answer: DHCP had failed when her lease came up for renewal, so she had lost her IP and default route! So why was she able to connect to IRC? Because she ran her IRC client on a server that was on the local link, and was therefore still able to reach this host even though she had no public IP, making it /seem/ that she was on the Internet.

I can only imagine the frustration of a user trying to troubleshoot a problem like this without knowing about this bug! :)

[Loye Young (loyeyoung)]

>he avahi default route has a very high metric set, this route will only
>ever be used by the kernel when there are no other routes available.

That's not the behavior we're seeing on Hardy fresh installs. According to
RFC 1122, multiple default routes *must* be supported, but in practice
that's honored more in the breach than in the observance. (In fairness, the
avahi protocol at least tries to implement some adherence; many networking
implementations don't. )

I stand by my contention that a "default" route is nonsensical for
link-local interfaces, but perhaps a more robust solution to the multiple
default routes issue is in order.

--
Loye Young
Isaac & Young Computer Company
Laredo, Texas
http://www.iycc.net

[Cyberax (alex-besogonov)]

I have a box with two network interfaces: DHCP to WAN and a statically configured local interface. Avahi-autpid constantly resets default route to local network so Internet traffic doesn't go anywhere.

Removing avahi fixes this problem for me.

[Alecz20 (alexguzu)]

avahi-autoipd gives me an IP address which overrides the settings in Network manager. This mean that after each reboot I have no valid network connection. I have to restart the network or re-configure Network manager each time.

syslog fragment:
[code]
Nov 15 17:23:25 vlad-studio avahi-autoipd(ath0)[5485]: Found user 'avahi-autoipd' (UID 105) and group 'avahi-autoipd' (GID 113).
Nov 15 17:23:25 vlad-studio avahi-autoipd(ath0)[5485]: Successfully called chroot().
Nov 15 17:23:25 vlad-studio avahi-autoipd(ath0)[5485]: Successfully dropped root privileges.
Nov 15 17:23:25 vlad-studio avahi-autoipd(ath0)[5485]: Starting with address 169.254.11.244
Nov 15 17:23:30 vlad-studio avahi-autoipd(ath0)[5485]: Callout BIND, address 169.254.11.244 on interface ath0
Nov 15 17:23:30 vlad-studio avahi-daemon[4803]: Joining mDNS multicast group on interface ath0.IPv4 with address 169.254.11.244.
Nov 15 17:23:30 vlad-studio avahi-daemon[4803]: New relevant interface ath0.IPv4 for mDNS.
Nov 15 17:23:30 vlad-studio avahi-daemon[4803]: Registering new address record for 169.254.11.244 on ath0.IPv4.
Nov 15 17:23:34 vlad-studio avahi-autoipd(ath0)[5485]: Successfully claimed IP address 169.254.11.244
[/code]

[Loye Young (loyeyoung)]

At IYCC, we've seen this problem over and over again, both on IYCC
computers and on Ubuntu computers of our customers . We've concluded
that avahi is a broken implementation of a bad idea, and the only
thing that seems to work reliably is to get it off the machine.

Here's the best solution:

# aptitude purge avahi-autoipd avahi-daemon avahi-utils libnss-mdns
# aptitude install ifmetric

Happy Trails,

Loye Young
Isaac & Young Computer Company
Laredo, Texas
http://www.iycc.net

On Sat, Nov 15, 2008 at 5:13 PM, Alecz20 <email address hidden> wrote:
> avahi-autoipd gives me an IP address which overrides the settings in
> Network manager. This mean that after each reboot I have no valid
> network connection. I have to restart the network or re-configure
> Network manager each time.

[Till Klampaeckel (till-php)]

I had the same issue (on Karmic Beta).

I can confirm the solution posted in #12.

I have to add that a reboot was required for me.

[Martin Pitt (pitti)]

avahi (0.6.25-1ubuntu5) karmic; urgency=low

  * debian/patches/11_avahi-autoipd.action-add-routes.patch: drop; this patch
    doesn't actually help anything for any network with an even remotely sane
    configuration, because hosts without a link-local address aren't going to
    route their response packets to us *anyway*, and having a standing default
    route on interfaces with no routable address causes network timeouts for
    any packets that *should* get a no route to host instead. LP: 99489.

 -- Steve Langasek <email address hidden> Sat, 17 Oct 2009 19:13:36 -0700