I have found that attempting to resolve a service's address when the service is provided by the local machine can be problematic. For some reason most hostnames seem fine, but in this case it is 100% reproducible on this machine when the hostname is axmm-00003.

Here is the final call that queues up this doomed case. Adding the AVAHI_LOOKUP_NO_ADDRESS flag prevents the issue.

avahi_service_resolver_new(client, interface, protocol, name, type, domain, AVAHI_PROTO_INET, AVAHI_LOOKUP_USE_MULTICAST, resolve_callback, userdata)

backtrace.txt.gz

Issuing two dbus method calls of GetNetworkInterfaceIndexByName, first with a short string and then with a long one, makes avahi-daemon point to uninitialised bytes when calling ioctl(SIOCGIFINDEX), according to valgrind.

DEBUG:root:TEST #1201: org.freedesktop.Avahi / org.freedesktop.Avahi.Server->GetNetworkInterfaceIndexByName with (('en0',),)
DEBUG:root:TEST #1202: org.freedesktop.Avahi / org.freedesktop.Avahi.Server->GetNetworkInterfaceIndexByName with (('AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA',),)

==7836== Syscall param ioctl(SIOCGIFINDEX) points to uninitialised byte(s)
==7836==    at 0x6206337: ioctl (syscall-template.S:81)
==7836==    by 0x6228076: if_nametoindex (if_index.c:48)
==7836==    by 0x40EAE0: msg_server_impl (dbus-protocol.c:376)
==7836==    by 0x5ACBE95: ??? (in /lib/x86_64-linux-gnu/libdbus-1.so.3.7.6)
==7836==    by 0x5ABEA20: dbus_connection_dispatch (in /lib/x86_64-linux-gnu/libdbus-1.so.3.7.6)
==7836==    by 0x414B35: dispatch_timeout_callback (dbus-watch-glue.c:105)
==7836==    by 0x4E3E647: avahi_simple_poll_dispatch (in /usr/lib/x86_64-linux-gnu/libavahi-common.so.3.5.3)
==7836==    by 0x406FD9: main (main.c:1256)
==7836==  Address 0xfff0004b0 is on thread 1's stack
==7836==  Uninitialised value was created by a stack allocation
==7836==    at 0x405D60: ??? (in /tmp/avahi-daemon-noasan)

Package: avahi-daemon
Version: 0.6.31-4

Avahi-daemon fills my logs with

Jun 11 07:38:57 lanthane avahi-daemon[2502]: Invalid response packet from host 172.23.36.97.
Jun 11 07:39:56 lanthane avahi-daemon[2502]: Invalid response packet from host 172.23.43.78.
Jun 11 07:39:56 lanthane avahi-daemon[2502]: Invalid response packet from host 172.23.36.97.

This will become a big problem as apparently Windows 10 causes this.

See also https://bugs.launchpad.net/ubuntu/+source/avahi/+bug/1342400
which references a patch that would help (haven't tested it myself yet,
may do today).

Maybe this bug needs to be merged with #639163
(which is already merged with #688061, although IMHO that's a different
problem).

Paul

See this line of code: https://github.com/lathiat/avahi/blob/master/avahi-autoipd/iface-linux.c#L144

It's processing an ifaddrmsg, but using a macro for an ifinfomsg. The sizes are different, and this means that it's at least getting the data wrong, and on an ARM platform I'm using, this makes avahi-autoipd crash.

Running avahi 0.6.32 for Bonjour Conformance tests and getting failures for Cable Change Handling test.

The operator disconnects and reconnects the device. The test tool verifies that the device repeats its address probing to verify that its address is still unique. The test tool denies the first probe and verifies that the device picks a new address and probes/announces again.

So once we reassociate the device with network, avahi-autoipd goes to starting state very late, it claims the ip address only after the BCT test ends, So it could never catch this conflicting IP and try to pick a new one.
Note that if i run it as a daemon in the background, it never catches the conflict.

I had to manually kill the autoipd daemon and start it manually before the test started. In that case it passes the test.

Same problem occurs in initial probing too, autoipd does not go to probing state unless i reboot the device or reconnect it to the network.

Do you have any suggestions or a fix for short term in order to fully support BCT? Is there any successful combination of avai and autoipd configuration to make it pass all tests?

Description of problem:
When autoip daemon is PROBING for a new ip and is receiving an arp request for the address being probed it is picking a new IP.
According to the RFC3927 this is only allowed when receiving an ARP probe (which has sender ip set to zero).

Version-Release number of selected component (if applicable):
avahi-0.6.31/avahi-autoipd/main.c

How reproducible:
always

Steps to Reproduce:

1. keep a running ping to a local link connected host
2. and reset that host
3. when the host is resetting the arp cache of the pinging computer will time out causing it so send arp requests for the old ip
4. check on wireshark, the autoipclient is announcing a new IP via ARP

Actual results:
the autoipclient is announcing a new IP via ARP

Expected results:
IP of autoip host must not change when receiving ARP requests for its currently propbed IP.

Additional info:

According to RFC3927, Section 2.2.1. Probe details:

An ARP Request constructed this way with an all-zero 'sender IP
address' is referred to as an "ARP Probe".

and

In addition, if during this period [checking if an address is already
in use] the host receives any ARP Probe where the packet's 'target IP
address' is the address being probed for, and the packet's 'sender
hardware address' is not the hardware address of the interface the
host is attempting to configure, then the host MUST similarly treat
this as an address conflict and select a new address as above.

I reported this bug the the manufactor of my failed device and their software guy sent a patch to freedesktop.org mailing list but it does not seem to be recognized.
In post http://marc.info/?l=freedesktop-avahi&m=139462973306278&w=2 is a patch appended which seems to fix the problem but I did not validate this patch myself.

see also: https://bugzilla.redhat.com/show_bug.cgi?id=1228379

Hi please resolve this error. I installed qt4 package from command terminal.

checking libintl.h presence... yes
checking for libintl.h... yes
checking for ngettext in libc... yes
checking for dgettext in libc... yes
checking for bind_textdomain_codeset... yes
checking for msgfmt... (cached) /usr/bin/msgfmt
checking for dcgettext... yes
checking if msgfmt accepts -c... yes
checking for gmsgfmt... (cached) /usr/bin/msgfmt
checking for xgettext... (cached) /usr/bin/xgettext
checking for pkg-config... yes
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for GLIB20... yes
checking for GOBJECT... yes
checking for gobject-introspection... no
checking for QT3... no
configure: error: Package requirements ( qt-mt >= 3.0.0 ) were not met:

No package 'qt-mt' found

Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.

Alternatively, you may set the environment variables QT3_CFLAGS
and QT3_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.

Hi,

After upgrading El-Capitan to Sierra version, Time Machine Backup stop working properly.

I'm trying to add Time Machine Disk, i saw the available disk, but got: "OSStatus error:65"

I tried to add a disk via: Go-> Connect to server-> afp://IPAddress - working perfectly.

please Advise.

We are applying this patch for a long time to fix provided Gentoo init.d scripts
https://gitweb.gentoo.org/repo/gentoo.git/plain/net-dns/avahi/files/avahi-0.6.x-openrc-0.9.x-init-scripts-fixes.patch

Thanks

Sorry for the noise, I've also asked this question on the avahi-list on freedesktop, but this list seems to be kind of dead.

I'm working on a platform consisting of a number of services which rely
on mDNS for mutual discovery to provide load balancing and failover -
all works fine with Avahi, no problems here.

I'm now trying to configure a system running with a number of services
on a single host with limited network connectivity. Most important is
that the machine is not allowed to use mDNS on the physical network
interface for administrative reasons.

My assumption was that this would be no problem and that things would
probably work just fine when restricting avahi-daemon to run on the lo
interface, an empty bridge or a dummy network interface. I've now spent
a few hours trying to get this to work, but to no avail.

Here are the steps I expected to work:

• Create a dummy network interface

  # modprobe dummy
  # ifconfig dummy0 172.16.0.0/24 multicast up

• Configure avahi-daemon to restrict itself to the dummy interface

  allow-interfaces=dummy0

• Start avahi daemon and discover services on the same machine:

  avahi-browse -a

Result: no results whatsoever.

The funny thing is that running wireshark on dummy0 shows actual mDNS
traffic happening: I see the initial announcments when avahi-daemon
starts and I see the requests on the network when running avahi-browse.
Still, no results are returned when browsing.

Can anobody point out my error?

In Debian, uninstalling a package does not remove conffiles. Those are only removed when explicitly requested via "--purge". Conffiles are typically files shipped in /etc. In case of avahi, this means the /etc/dhclient hooks can be installed but the actual binary is missing. The following bug was filed as a result.

Dear Maintainer,

If one removes (but does not purge) avahi-autoipd, one is likely to
start seeing this sort of thing in the system logs:

root: /etc/dhcp/dhclient-exit-hooks.d/zzz_avahi-autoipd returned non-zero exit status 127

=-=-=-=-=-=-=-=-
For those finding this as a result of a search for the above error message:

The problem is that the config files are left in place when one removes
a package, including these problematic scripts. To remove them one needs
to purge the package, thus:

 sudo apt-get purge avahi-autoipd

=-=-=-=-=-=-=-=-

The bug in the package could be fixed by changing the scripts to use
this line instead (BTW the reason for inverting the test is that that
ensures that the script's return value is 0 if the file is missing):

[ ! -x /usr/sbin/avahi-autoipd ] || /usr/sbin/avahi-autoipd -wD $interface 2> /dev/null

I can carry this as a downstream patch, but if you see value in having this fixed upstream, feel free to apply the patch at

http://anonscm.debian.org/cgit/pkg-utopia/avahi.git/tree/debian/patches/0001-avahi-autoipd-fix-dhclient-hooks-to-check-for-avahi-.patch

Thanks for considering

From: Christian Hesse [email protected]

Avahi used to set matches that were too restrictive. This worked with
legacy dbus, however.

With kdbus libavahi-client breaks: The signals are not forwarded due to
missing match. So match everything Avahi tells us.

We are applying for ages the attached patch on Gentoo to allow us to optionally depend on GTK for gtk-utils... maybe it could be upstreamed finally :)
https://gitweb.gentoo.org/repo/gentoo.git/plain/net-dns/avahi/files/avahi-0.6.30-optional-gtk-utils.patch

Thanks

I have a daemon application that uses the avahi library (0.6.31-4ubuntu1.1) to start an avahi-client for discovering peer applications on the network. The application is running on Ubuntu 14.04.5. The applications are using IPv6.

When a resolver is initially found, the IP address is cached for subsequent peer communication and the AvahiServiceResolver object is cached so the daemon can pick up on changes to the service during runtime.

I've noticed that when a peer application disappears for long enough such that the resolve timeout is hit ("Timeout reached") and then reappears with the same service name but a new IP address, the resolve_callback is called with the old IP address.

I can reproduce this via:

1. Start the daemon on two machines and allow them to discover each other.
2. Shut down network interface on machine A.
3. Change IPv6 address on machine A.
4. Wait for the resolve_callback on machine B's daemon to be called with the AVAHI_RESOLVER_FAILURE event for "Timeout reached". 180 seconds of waiting is sufficient.
5. Start up the network interface on machine A.
6. See the resolve_callback on machine B's daemon to be called with the AVAHI_RESOLVER_FOUND event, but the old AvahiAddress.

If I don't wait long enough in step 4 (e.g. 90 seconds or less), the resolve_callback is called with the new address as expected.

Using dbus-monitor (dbus-monitor --system "sender='org.freedesktop.Avahi'"), I can see the message being sent to the avahi-client with the old IP address.

This may be the same bug mentioned here: https://github.com/rosjava/zeroconf_jmdns_suite/wiki/Understanding-Avahi

We are applying on Gentoo for a long time the following patch to allow us to build the client without the daemon... maybe this could be upstreamed finally :)

https://gitweb.gentoo.org/repo/gentoo.git/plain/net-dns/avahi/files/avahi-0.6.31-build-client-without-daemon.patch

We are needing to create this both links for getting full mdns and hown compatibility:
ln -s avahi-compat-howl.pc /usr/lib/pkgconfig/howl.pc
ln -s avahi-compat-libdns_sd/dns_sd.h /usr/include/dns_sd.h

Maybe this should be done automatically on make install phase when the compat is enabled

Balaji X. Srinivas bxsrinivas@... writes:

I figured out why avahi-0.6.31 package fails the apple bonjour conformance
test(v1.3.0) for test case SRV PROBING/ANNOUNCEMENTS.

The Bonjour conformance test requires that the hostname and service name on
the device be resolved at the same time during one point.However avahi
package waits until the hostname is resolved before resolving the service
names.

And also noticed one thing that when device in the state of resolving the
hostname,device could not probe service with new name though it logged info
message as service name conflict.

And so the bonjour test logs following,

"SRV Probing: Device didn't send a new probe after test issued a probe
denial in response to device's previous query".

And also verified on more case like, when device gets locked to hostname
and then device should be able to probe SRV successfully.

I am yet to figure out the actual requirement of this with RFC document.

ref also: https://bugs.launchpad.net/ubuntu/+source/avahi/+bug/1409872

On my Yocto-Linux board with Linux kernel 4.4.16 I installed avahi and used avahi-autoipd to assign a link local address to the interface tap0.

tap0      Link encap:Ethernet  HWaddr 62:A5:8B:82:A6:57
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:80514 errors:0 dropped:1974 overruns:0 frame:0
          TX packets:74462 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:6840730 (6.5 MiB)  TX bytes:5739242 (5.4 MiB)

tap0:avahi Link encap:Ethernet  HWaddr 62:A5:8B:82:A6:57
          inet addr:169.254.8.141  Bcast:169.254.255.255  Mask:255.255.0.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

Afterwards, I set the default gateway towards my internet router, which had NAT enabled and the address 169.254.123.1. The routing table looked as follows:

 ~# route -n
 Kernel IP routing table
 Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
 0.0.0.0         169.254.123.1   0.0.0.0         UG    0      0        0 tap0
 169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 tap0

Now, when I tried to ping the DNS-Server 8.8.8.8, I didn't get a reply. Please find below the result of tcpdump seen from my internet router:
12:33:41.910618 IP (tos 0x0, ttl 64, id 54387, offset 0, flags [DF], proto ICMP (1), length 84) 0.0.0.0 > google-public-dns-a.google.com: ICMP echo request, id 28940, seq 13, length 64 12:33:42.907553 IP (tos 0x0, ttl 64, id 54473, offset 0, flags [DF], proto ICMP (1), length 84) 0.0.0.0 > google-public-dns-a.google.com: ICMP echo request, id 28940, seq 14, length 64 12:33:43.910456 IP (tos 0x0, ttl 64, id 54560, offset 0, flags [DF], proto ICMP (1), length 84) 0.0.0.0 > google-public-dns-a.google.com: ICMP echo request, id 28940, seq 15, length 64
The reason for not getting a reply, is because the source address resulted as 0.0.0.0. Why is that?

In order to make the ping work, it was necessary to use the option "-I {address}" and indicate the source address of my tap0.
If I kill avahi-autoipd and manually assign a link local address to the tap0 interface, everything is working as expected (i.e. the source address is correct without having to explicitely indicate it). Therefore, I assume there must be a bug in avahi.

I have a machine with publishing disabled (avahi-daemon.conf attached) and every two minutes the system log has a set of entries like this:

Nov 29 12:53:53 x avahi-daemon[413]: Registering new address record for fe80::c68e:8fff:fef5:d20f on wlan0.*.
Nov 29 12:53:53 x avahi-daemon[413]: iface.c: avahi_server_add_address() failed: Not permitted
Nov 29 12:53:53 x avahi-daemon[413]: Registering new address record for 192.168.123.5 on wlan0.IPv4.
Nov 29 12:53:53 x avahi-daemon[413]: iface.c: avahi_server_add_address() failed: Not permitted

Indeed, most of the system log consists of notifications that avahi is trying and failing to do something it has been told not to do.

avahi-daemon.conf.txt

At the moment legacy unicast responses do not get split over several smaller ones when the response is going to be larger than 512 bytes, resulting in many of the services being omitted from unicast responses.

Here is one of the many entries in the syslog when avahi is responding to a service query and there are several matches to the query:

Oct 16 12:47:22 axpi avahi-daemon[405]: Record [Local\0321._XYZ-SERVICE._tcp.local#011IN#011SRV 0 0 7400 axpi.local ; ttl=120] not fitting in legacy unicast packet, dropping.

These log messages are added for each service matching the query which cannot fit in the 512 byte packet.

The relevant code is at avahi-core/server.c -> avahi_server_generate_response

if (legacy_unicast) {
    AvahiDnsPacket *reply;
    AvahiRecord *r;

    if (!(reply = avahi_dns_packet_new_reply(p, 512 + AVAHI_DNS_PACKET_EXTRA_SIZE /* unicast DNS maximum packet size is 512 */ , 1, 1)))
        return; /* OOM */

    while ((r = avahi_record_list_next(s->record_list, NULL, NULL, NULL))) {

        append_aux_records_to_list(s, i, r, 0);

        if (avahi_dns_packet_append_record(reply, r, 0, 10))
            avahi_dns_packet_inc_field(reply, AVAHI_DNS_FIELD_ANCOUNT);
        else {
            char *t = avahi_record_to_string(r);
            avahi_log_warn("Record [%s] not fitting in legacy unicast packet, dropping.", t);
            avahi_free(t);
        }

        avahi_record_unref(r);
    }

    if (avahi_dns_packet_get_field(reply, AVAHI_DNS_FIELD_ANCOUNT) != 0)
        avahi_interface_send_packet_unicast(i, reply, a, port);

    avahi_dns_packet_free(reply);

}

*edited since researching the topic some more

I'm not sure what consequences something like this would cause : rlbartle@f4b7859

For context, see

• https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211345
• https://bugs.chromium.org/p/chromium/issues/detail?id=626377

I would like to propose merging the nss-mdns package into this one, making avahi the definitive upstream for that package. nss-mdns has a hard requirement on Avahi in its recommended configuration, and there are outstanding patches from FreeBSD that have not been accepted upstream.

The existing upstream is at http://0pointer.de/lennart/projects/nss-mdns/ and http://git.0pointer.net/nss-mdns.git/ but has received no updates since 2007.

I can prepare the patches if this idea is acceptable. My further plans include:

• unifdef many of the compile options, specifically the non-Avahi support which has been long deprecated
• fix up and merge the outstanding FreeBSD ports patches
• then finally look into adding some new functionality to nss-mdns

My ultimate goal here is to allow Avahi + nss-mdns to coexist with DNS servers that provide .local resolution, using the SOA algorithm described here: https://support.apple.com/en-us/HT201275. This would allow the elimination of the problematic scripts currently used by distributions that hard-stop Avahi when such a configuration is detected.

I have the following setup:

1. device-1 fqdn is device-1.local;
2. device-2 fqdn is device-2.local;
3. On device-1 I add the following CNAME record via avahi_entry_group_new and avahi_entry_group_add_record - device-2.local CNAME device-1.local;
4. Entry group state is changed to ENTRY_GROUP_ESTABLISHED and now if I ping device-2.local from device-1 I get device-1's address, if I ping it from device-2 I get device-2 addres.

Is that correct behavior? I expected state of entry group to be changed to ENTRY_GROUP_COLLISION so that I can choose alternative name.

Thanks!

from #gnome-hackers/hadess

The current D-BUS API requires that you create an object, which then immediately starts returning signals.

The C Client appears to subscribe to all signals up front, however the Python API and for example frameworks like GDBUS would have you call 'connect_to_signal' once the object is created and the path is known. Signals might arrive in this time frame.

Investigate further if this actually occurs and what possible fix there might be, other than an obvious Start method. Does d-bus have some way around this, what do others do?

Example in avahi-python/avahi-bookmarks.in:
browser = dbus.Interface(self.bus.get_object(avahi.DBUS_NAME, self.server.ServiceBrowserNew(avahi.IF_UNSPEC, avahi.PROTO_UNSPEC, stype, domain, dbus.UInt32(0))), avahi.DBUS_INTERFACE_SERVICE_BROWSER)
browser.connect_to_signal('ItemNew', self.new_service)
browser.connect_to_signal('ItemRemove', self.remove_service)

avahi-core/core.h:

• int publish_aaaa_on_ipv4; /**< Publish an IPv4 A RR on IPv6 sockets */
• int publish_aaaa_on_ipv4; /**< Publish an IPv6 AAAA RR on IPv4 sockets */

see patch on mail list, thanks

The website http://avahi.org/ is down fro me, http://avahi.org/download seems to work. Should the URL in the readme be updated?

https://github.com/lathiat/avahi/blob/master/README#L9

I would like to request support for a user-configured MTU. In the case of a WLAN mixed with a jumbo-frames configured LAN, Multicast DNS packets that exceed the WLAN MTU are silently dropped.
I would see this as being a simple "mtulimit" setting, which would replace the discovered hardware MTU if the setting is lower. This would allow the multicast packets to be sent with the correct maximum size.

Yesterday i created a small network with VMWare Fusion. But i can't get any RR from my bind via firefox and curl. But dig and nslookup worked... so i found out that avahi made some problems with .local domains. I deactivate it reboot and now everything is working. :D Just as information for you :P

I currently use netnamespaces and so do completely separate the interfaces from each other.

The issue now is that im unable to start two avahi daemons concurrently and so i'am unable to have separated services for each interace/namespace configured.

We should consider allow avahi to configure its path to the pid and the services directory.

We need to apply this patch on Gentoo, still with latest release. Thanks
https://gitweb.gentoo.org/repo/gentoo.git/plain/net-dns/avahi/files/avahi-0.6.31-fix-locale-build.patch

Hello All,

I am currently facing an issue with Avahi-daemon & Avahi-client

The issue is I do not see Avahi-client like avahi-browse getting update from Avahi-daemon for the change in Registering new address record. It show the old Withdrawing address record in the avahi-browse & it never gets updated. If I restart the avahi-browse then I see the new registered address record.

In my case the old Withdrawing address is the IPv6 link local address & the Registering new address is the IPv6 global address assigned to that interface by Radvd.
It is easy to reproduce this issue.

Please let me know if anyone else has also faced the same issue. Or is there any know solution for this issue.

avahi-daemon[325]: Registering new address record for fa10:53ba:e9a0:de12:58a1:d8ff:fedd:8b1a on eth0*.

avahi-daemon[325]: Withdrawing address record for fe80::58a1:d8ff:fedd:8b1a on eth0.

Thanks

From: Christian Hitz <christian.hitz () digitalstrom ! com>
Hi,

we noticed that avahi-autoipd selects a new IP when it receives an ARP
request during the probe phase.

According to RFC3927, Section 2.2.1. Probe details:

An ARP Request constructed this way with an all-zero 'sender IP
address' is referred to as an "ARP Probe".

and

In addition, if during this period [checking if an address is already
in use] the host receives any ARP Probe where the packet's 'target IP
address' is the address being probed for, and the packet's 'sender
hardware address' is not the hardware address of the interface the
host is attempting to configure, then the host MUST similarly treat
this as an address conflict and select a new address as above.

When receiving an ARP packet during probe avahi-autoipd does not check
if the 'sender IP address' is all-zero and therefore if the packet is an
ARP Probe.

The attached patch adds this check.

Regards,
Christian

http://marc.info/?l=freedesktop-avahi&m=139462973306278&w=2
https://bugzilla.redhat.com/show_bug.cgi?id=1228379

From:
http://stackoverflow.com/questions/25439158/avahi-daemon-gets-stuck-registering-a-service-im-publishing-with-avahi-publish/30757900#30757900

I've noticed that ticket 201 has been around for some while on the Avahi site. Though I couldn't even register there... Looks like development on this project has fallen off. We experienced a similar problem. The below addressed it (for us):

diff --git a/avahi-core/server.c b/avahi-core/server.c
index 69a1d02..03d4fc1 100644
--- a/avahi-core/server.c
+++ b/avahi-core/server.c
@@ -1216,8 +1216,8 @@ static void register_browse_domain(AvahiServer *s) {
 static void register_stuff(AvahiServer *s) {
     assert(s);

-    server_set_state(s, AVAHI_SERVER_REGISTERING);
     s->n_host_rr_pending ++; /** Make sure that the state isn't changed tp AVAHI_SERVER_RUNNING too early */
+    server_set_state(s, AVAHI_SERVER_REGISTERING);

     register_hinfo(s);
     register_browse_domain(s);

From section 10.4 "Cache Flush on Failure Indication" in RFC 6762:

The software implementing the Multicast DNS resource record cache should provide a mechanism so that clients detecting stale rdata can inform the cache.

I've been searching for a way to do this with Avahi but I haven't found one. Have I missed something? If not, would it be possible to add this feature?

Generally can likely just make the interfaces not relevant and relevant again.

Some thought to future sleep proxy implementation may be necessary however.

The bottom message at the window of avahi browser shows the bottom text is not in italics, but the tags for italics are shown instead.

On Gentoo, Arch and many other distributions we are needing to provide this missing link to get avahi started automatically on demand by systemd when needed:
ln -s avahi-daemon.service /usr/lib/systemd/system/dbus-org.freedesktop.Avahi.service

Thanks

I'm trying to permanently register a subdomain project.machine.local for my computer in /etc/avahi/hosts. Doing that and restarting avahi-daemon gives me an error in syslog:

avahi-daemon[24327]: Static host name project.machine.local: avahi_server_add_address failure: Local name collision

I can register the name with avahi-publish when giving the --no-reverse option:

$ avahi-publish -a -R project.machine.local 192.168.178.13
Established under name 'project.machine.local'

It would be nice if there was a way to specify this option in the hosts file, too.

I'm running Ubuntu 16.04 20160601 on a smartos box.

When I try and start the avahi-daemon with the default parameters it fails:

root@ubuntu:/etc/systemd# /usr/sbin/avahi-daemon --debug
Process 62994 died: No such process; trying to remove PID file. (/var/run/avahi-daemon//pid)
Found user 'avahi' (UID 108) and group 'avahi' (GID 112).
Successfully dropped root privileges.
avahi-daemon 0.6.32-rc starting up.
chroot.c: chroot() helper started
Successfully called chroot().
Successfully dropped remaining capabilities.
Failed to initialize inotify: No such file or directory
chroot.c: chroot() helper got command 02
No service file found in /etc/avahi/services.
SO_REUSEPORT failed: Protocol not available
SO_REUSEPORT failed: Protocol not available
netlink.c: bind(): Permission denied
on: starting up: iface-linux.c:380: avahi_interface_monitor_sync: Assertion `m' failed.
chroot.c: chroot() helper exiting with return value 0
Aborted (core dumped)

When I start it up with root privileges it works just fine:

root@ubuntu:/etc/systemd# /usr/sbin/avahi-daemon --debug --no-drop-root
Process 63008 died: No such process; trying to remove PID file. (/var/run/avahi-daemon//pid)
avahi-daemon 0.6.32-rc starting up.
No service file found in /etc/avahi/services.
SO_REUSEPORT failed: Protocol not available
SO_REUSEPORT failed: Protocol not available
Joining mDNS multicast group on interface eth0.IPv6 with address fe80::d048:92ff:fea6:b27f.
IPV6_ADD_MEMBERSHIP failed: Protocol not available
Joining mDNS multicast group on interface eth0.IPv4 with address 10.0.0.11.
New relevant interface eth0.IPv4 for mDNS.
Network interface enumeration completed.
Registering new address record for fe80::d048:92ff:fea6:b27f on eth0.*.
Registering new address record for 10.0.0.11 on eth0.IPv4.
Unhandled cmsg_type: 0
Unhandled cmsg_type: 0
Unhandled cmsg_type: 0
Server startup complete. Host name is ubuntu.local. Local service cookie is 1360304338.
Unhandled cmsg_type: 0
Unhandled cmsg_type: 0
Unhandled cmsg_type: 0
Unhandled cmsg_type: 0

I can add more debug information if that would be helpful.

Any chance of supporting SSDP in the near future ? Proxying multicast SSDP traffic in between different broadcast domains.

I am wondering if it is possible to compile avahi for Windows environments? (mingw/msys/cygwin or even MSVC?)

Best regards,
Thomas.

Getting error while ./configure avahi-daemon project. Please verify this one or please correct me

checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking how to create a pax tar archive... gnutar
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking whether make supports nested variables... (cached) yes
checking for stow... no
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking for gcc option to accept ISO C99... -std=gnu99
checking whether we are using the GNU C++ compiler... no
checking whether /usr/bin/arm-linux-gnueabi-gcc accepts -g... no
checking dependency style of /usr/bin/arm-linux-gnueabi-gcc... gcc3
checking how to run the C preprocessor... gcc -std=gnu99 -E
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking minix/config.h usability... no
checking minix/config.h presence... no
checking for minix/config.h... no
checking whether it is safe to define EXTENSIONS... yes
checking how to run the C preprocessor... gcc -std=gnu99 -E
checking whether ln -s works... yes
checking whether make sets $(MAKE)... (cached) yes
checking whether gcc -std=gnu99 needs -traditional... no
checking whether libssp exists... no
checking whether stack-smashing protection is available... yes
checking whether stack-smashing protection is buggy... no
checking whether gcc -std=gnu99 accepts -fstack-protector... yes
checking whether /usr/bin/arm-linux-gnueabi-gcc accepts -fstack-protector... no
checking how to print strings... printf
checking for a sed that does not truncate output... /bin/sed
checking for fgrep... /bin/grep -F
checking for ld used by gcc -std=gnu99... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking the maximum length of command line arguments... 1572864
checking how to convert x86_64-unknown-linux-gnu file names to x86_64-unknown-linux-gnu format... func_convert_file_noop
checking how to convert x86_64-unknown-linux-gnu file names to toolchain format... func_convert_file_noop
checking for /usr/bin/ld option to reload object files... -r
checking for objdump... objdump
checking how to recognize dependent libraries... pass_all
checking for dlltool... no
checking how to associate runtime and link libraries... printf %s\n
checking for ar... ar
checking for archiver @file support... @
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /usr/bin/nm -B output from gcc -std=gnu99 object... ok
checking for sysroot... no
checking for a working dd... /bin/dd
checking how to truncate binary pipes... /bin/dd bs=4096 count=1
checking for mt... mt
checking if mt is a manifest tool... no
checking for dlfcn.h... yes
checking for objdir... .libs
checking if gcc -std=gnu99 supports -fno-rtti -fno-exceptions... no
checking for gcc -std=gnu99 option to produce PIC... -fPIC -DPIC
checking if gcc -std=gnu99 PIC flag -fPIC -DPIC works... yes
checking if gcc -std=gnu99 static flag -static works... yes
checking if gcc -std=gnu99 supports -c -o file.o... yes
checking if gcc -std=gnu99 supports -c -o file.o... (cached) yes
checking whether the gcc -std=gnu99 linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
checking how to run the C++ preprocessor... /lib/cpp
checking whether the /usr/bin/arm-linux-gnueabi-gcc linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
libtool.m4: error: problem compiling CXX test program
checking for /usr/bin/arm-linux-gnueabi-gcc option to produce PIC... -DPIC
checking if /usr/bin/arm-linux-gnueabi-gcc PIC flag -DPIC works... no
checking if /usr/bin/arm-linux-gnueabi-gcc static flag works... no
checking if /usr/bin/arm-linux-gnueabi-gcc supports -c -o file.o... no
checking if /usr/bin/arm-linux-gnueabi-gcc supports -c -o file.o... (cached) no
checking whether the /usr/bin/arm-linux-gnueabi-gcc linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
checking dynamic linker characteristics... (cached) GNU/Linux ld.so
checking how to hardcode library paths into programs... unsupported
checking whether the C++ compiler works... no
configure: error: in /home/jagan/Mywork/avahi-0.6.32': configure: error: The C++ compiler does not work Seeconfig.log' for more details

We got this downstream report some time ago:
https://bugs.gentoo.org/show_bug.cgi?id=528722

When activating avahi for point 2 point devices (tun/tap) the daemon uses the destination address instead the local device address.

To fix that, the user provided the following patch... then, it would be nice if it could be reviewed by upstream and accepted if it's really ok. Thanks a lot:
https://528722.bugs.gentoo.org/attachment.cgi?id=388928

According to https://tools.ietf.org/html/rfc6763#section-6.5 :

The value is opaque binary data. Often the value for a particular attribute will be US-ASCII [RFC20] or UTF-8 [RFC3629] text, but it is legal for a value to be any binary data.

However, the current static XML service definition only allows printable characters to be included as TXT record value (http://linux.die.net/man/5/avahi.service).

From an old @poettering message to the list (https://lists.freedesktop.org/archives/avahi/2010-August/001915.html):

The C API allows you to create binary TXT fields very easily. However, this is not supported in the XML definition for static services, simply because there is no nice way to include binary data in XML files.

What about an attribute in the XML 'text-record' tag?
<txt-record value="binary">"val=0xf0a9"</txt-record>

Sleep proxy server and client would be nice

Someone wrote a client in python:
https://github.com/awein/SleepProxyClient

Enabling IPv6 by default on 0.6.32, the issue of duplicate services on IPv4/IPv6 occurs.

Document guidelines on how to best handle this. Just merging names may not be the best strategy, but may also be "good enough"

This issue also (already) occurs with multiple network interfaces

References:
https://bugzilla.redhat.com/show_bug.cgi?id=821127#c6

Summary:
When ipv6.ip6-privacy 2 (enabled, prefer temporary IP) is set, eventually preferred_lft reaches 0 seconds and that address becomes deprecated at which point avahi-daemon goes crazy and starts to flood the journal every three seconds. Fully 80% of the journal is full of these messages.

Jan 25 10:50:20 f23m.localdomain avahi-daemon[15925]: Registering new address record for 2601:282:702:b65c:3c32:c570:6607:a8c on enp2s0f0..
Jan 25 10:50:20 f23m.localdomain avahi-daemon[15925]: Withdrawing address record for 2601:282:702:b65c:3c32:c570:6607:a8c on enp2s0f0.
Jan 25 10:50:23 f23m.localdomain avahi-daemon[15925]: Registering new address record for 2601:282:702:b65c:3c32:c570:6607:a8c on enp2s0f0..
Jan 25 10:50:23 f23m.localdomain avahi-daemon[15925]: Withdrawing address record for 2601:282:702:b65c:3c32:c570:6607:a8c on enp2s0f0.
Jan 25 10:50:26 f23m.localdomain avahi-daemon[15925]: Registering new address record for 2601:282:702:b65c:3c32:c570:6607:a8c on enp2s0f0.*.
Jan 25 10:50:26 f23m.localdomain avahi-daemon[15925]: Withdrawing address record for 2601:282:702:b65c:3c32:c570:6607:a8c on enp2s0f0.

ipv6 privacy extension RFC4941 behavior was default in Fedora 22 but due to a bug (listed below) it's not default in Fedora 23, otherwise this avahi behavior would be significantly more widespread.

Reproduced on two systems with following configurations:
Fedora 23 Server on Intel NUC
kernel 4.4.0-1.fc24.x86_64
avahi-0.6.31-43.fc23.x86_64 ##default avahi-daemon.conf

Fedora 23 Workstation on Macbook Pro
kernel 4.4.0-1.fc24.x86_64
avahi-0.6.32-0.4.rc.fc23.x86_64

Red Hat BZ version of this report:
avahi-daemon permanently registers and withdraws address record
https://bugzilla.redhat.com/show_bug.cgi?id=1221676

NM generated IPv6 addresses leak your MAC address to the world
https://bugzilla.redhat.com/show_bug.cgi?id=1279242

Is possible to build/use Avahi in Android?
If yes, how?
Are there any known difference from the "normal build" besides the use of ndk/cross-compiling?

I am thinking in use dns-sd in Android from c++ code, but don't know if there is some kind of library that allows this.

Thanks!

avahi-0.6.32 is not there. Intentional? (Is github the place downstreams should fetch releases from now?)

Looks like a bug.

Squashes like a bug.
:-)

File:
configure

Looks like:

BUILD_CLIENT="no   (You need avahi-daemon and D-Bus!)"

if "x$HAVE_DBUS" = "xyes" ; then
    BUILD_CLIENT=yes
fi

Should have "test" added be changed to:

BUILD_CLIENT="no   (You need avahi-daemon and D-Bus!)"

if test "x$HAVE_DBUS" = "xyes" ; then
    BUILD_CLIENT=yes
fi

After doing so I was able to run conifig and install without problems.

Wayne Sallee
[email protected]
http://www.WayneSallee.com

When the browse domains are changed, we simply update the internal config with no change tracking.

Notification should be sent to DomainBrowser instances watching this information (e.g. avahi-browse -D)