Hello Trent, I have also built avahi 0.6.32 and 0.7 from sources and got the same results on Debian Jessie. For me this looks like it has more to do with the network stack and/or Linux kernel rather than Avahi itself. However, I might be wrong here.
I will stick with the solution right now, to use Debian Stretch where possible. For the other case I will use an additional device (e.g. a RPi with PiVPN) for the OpenVPN connection. -- Alexander Trent Lloyd writes: > Hi Alexander, > > This was a known bug that we fixed in 0.6.32 > > Relevant commit is here: > https://github.com/lathiat/avahi/commit/8b3f8e4a63f09d9c9f86dfaddb0681cc612a79eb#diff-8433b64538fa06175a391bc55285b287 > > I'm not sure if there's a Debian process to get these fixes pushed into > the older releases or not, perhaps if there is you can check the process > and perhaps file a bug for that? > > - Trent > > On 13/07/17 00:49, Alexander Rössler wrote: >> I have discovered a problem with avahi-daemon and the peer to peer interfaces >> tun0 created by OpenVPN. I tested on Debian Wheezy, Jessie and Stretch >> and can confirm that the problem exists at least on Wheezy and Jessie. >> >> $ ip a >> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group >> default >> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 >> inet 127.0.0.1/8 scope host lo >> inet6 ::1/128 scope host >> valid_lft forever preferred_lft forever >> 2: eth0: <BROADCAST,MULTICAST,DYNAMIC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast >> state UP group default qlen 1000 >> link/ether 78:a5:04:cc:90:ee brd ff:ff:ff:ff:ff:ff >> inet 10.0.0.5/24 brd 10.0.0.255 scope global eth0 >> inet6 fe80::7aa5:4ff:fecc:90ee/64 scope link >> valid_lft forever preferred_lft forever >> 9: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast >> state UNKNOWN group default qlen 100 >> link/none >> inet 10.10.10.161 peer 10.10.10.162/32 scope global tun0 >> >> $ sudo service 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 Wed 2017-07-12 16:22:35 UTC; 21min ago >> Main PID: 9623 (avahi-daemon) >> Status: "avahi-daemon 0.6.31 starting up." >> CGroup: /system.slice/avahi-daemon.service >> ├─9623 avahi-daemon: running [beaglebone.local >> └─9624 avahi-daemon: chroot helpe >> >> Jul 12 16:28:28 beaglebone avahi-daemon[9623]: Joining mDNS multicast group >> on interface tun0.IPv4 with address 10.10.10.158. >> Jul 12 16:28:28 beaglebone avahi-daemon[9623]: New relevant interface >> tun0.IPv4 for mDNS. >> Jul 12 16:28:28 beaglebone avahi-daemon[9623]: Registering new address >> record for 10.10.10.158 on tun0.IPv4. >> Jul 12 16:28:38 beaglebone avahi-daemon[9623]: Withdrawing address record >> for 10.10.10.158 on tun0. >> Jul 12 16:28:38 beaglebone avahi-daemon[9623]: Leaving mDNS multicast group >> on interface tun0.IPv4 with address 10.10.10.158. >> Jul 12 16:28:38 beaglebone avahi-daemon[9623]: Interface tun0.IPv4 no longer >> relevant for mDNS. >> Jul 12 16:28:38 beaglebone avahi-daemon[9623]: Withdrawing workstation >> service for tun0. >> Jul 12 16:43:46 beaglebone avahi-daemon[9623]: Joining mDNS multicast group >> on interface tun0.IPv4 with address 10.10.10.162. >> Jul 12 16:43:46 beaglebone avahi-daemon[9623]: New relevant interface >> tun0.IPv4 for mDNS. >> Jul 12 16:43:46 beaglebone avahi-daemon[9623]: Registering new address >> record for 10.10.10.162 on tun0.IPv4. >> >> As you can see avahi-daemon registers to the peer address instead of the >> local address of the tun0 interfaces. Therefore, service discovery using >> unicast DNS packages does not work. The same setup works fine with >> Debian Stretch. I also tried the latest master on Debian Jessie and got >> the same results. >> >> Is there a way to force the IP address avahi-daemon uses for a given >> interface? Or does someone know another way to "unconfuse" avahi-daemon >> with this kind of setup? >> >> Btw. on wheezy I noticed that avahi first joins the correct mutlicast >> group with the IP address 10.10.10.161 and then disconnects and joins >> the wrong multicast address with IP address 10.10.10.162. >> >> Thanks and best regards, >> Alexander >> _______________________________________________ >> avahi mailing list >> avahi@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/avahi _______________________________________________ avahi mailing list avahi@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/avahi
