Discussion:
[avahi] Avahi tosses unicast packets from same host
jimc
2017-05-13 19:03:07 UTC
Permalink
This is for avahi-0.6.31-26.1.x86_64 from OpenSuSE "Leap" 42.1. I've
written a set of simple test scripts that check if daemons are
functioning, restarting them if not. The one for avahi-daemon basically
does: (illustrated executing on host kermit)
dig -p 5353 +short @kermit kermit.local. A
No RR's are returned and the query times out. In syslog I see
"Received packet from invalid interface." If I ask about Kermit but
executing on any different host, the correct content is returned, and
similarly for all pairs of hosts on my net: a unicast query to the
execution host yields nothing, but to a different host is answered
reliably. Every query fails/succeeds equally, e.g. an AAAA record, or
asking for the PTR at _ssh._tcp.local. It fails/succeeds equally when
the IPv4 or IPv6 address of the server is used. Multicast queries to
224.0.0.251 and ff02::fb are answered even from the execution host.

I tracked this down to (source)/avahi-core/server.c ; see
dispatch_packet() in that file. The AvahiIfIndex (believed same as
/sys/class/net/${IFC}/ifindex) is 1, identifying lo (loopback) on my
machine, and its i->announcing flag is zero (as it should be). But the
contingency at the start of this subroutine causes packets received from
non-announcing interfaces to be tossed with the "invalid interface"
message, explaining the symptom. But I don't see how multicast packets
escape the ax.

I wish a distinction could be made between interfaces (e.g. lo) whose
address should not be announced, versus deny-interfaces members.

There's a second issue which I should mention, though it may be hard to
fix. On my net, Linux boxes generally have a fixed IP gotten by DHCP,
plus a RFC 4862 address (prefix + EUI-64). Avahi-daemon lets the kernel
pick which one to send from. "dig", but not Perl's Net::DNS::Resolver,
rejects packets from other than the address it sent the (unicast) query
to, and so from half the machines, Avahi responses are rejected noisily
by "dig" but are functional on other software. I wish that avahi-daemon
would respond to unicast queries (of course not multicast) using the
source address in the query packet.

/etc/avahi/avahi-daemon.conf follows, with comments removed. Changes
from (source>/avahi-daemon/avahi-daemon.conf are noted.

[server]
use-ipv4=yes
use-ipv6=yes # Local mod, turned on
allow-interfaces=wlan0 # Local mod to explicitly allow wlan0
ratelimit-interval-usec=1000000
ratelimit-burst=1000
[wide-area]
enable-wide-area=yes
[publish]
publish-a-on-ipv6=yes # Local mod, turned on
[reflector]
# no reflector
[rlimits]
rlimit-core=0
rlimit-data=4194304
rlimit-fsize=0
rlimit-nofile=768
rlimit-stack=4194304
rlimit-nproc=3

- --
James F. Carter Email: ***@jfcarter.net
Web: http://www.math.ucla.edu/~jimc (q.v. for PGP key)
Trent Lloyd
2017-05-20 05:14:05 UTC
Permalink
Hi Jim,

Thanks for your observations.

I actually had some issues with loopback raised to me recently by Till
Kamppeter with regards to the IPPUSBXD project
(https://github.com/tillkamppeter/ippusbxd/) who wanted to be able to
publish a service locally on the machine and not export it. In a way
that's similar in scope to what you are talking about here.

I need to review the handling of loopback and perhaps can fix your issue
at the same time. As part of his fix I am probably going to always
activate the loopback interface which will fix your issue anyway at
least partly (though wouldn't fix the deny-interfaces side). I am not
sure I want to accept unicast queries on "disabled" interfaces, that's
probably a bad idea but it probably does make sense to try and answer
them from localhost. So hopefully that fix will suffice.


Not activating loopback (as well as having IPv6 disabled) were
originally mechanisms to 'simply' solve the problem of duplicate
services - the same name appearing on multiple interfaces which is a
difficult problem because they may actually be different services -
there's no way to tell for sure. I need to revisit these problems and
try to find a more elegant solution / suggestion to interface authors.


On the issue with the source address, that's also a problem that shows
up in a number of areas. I would agree that it makes most sense to
reply from the originally queried address.

Can you open an issue for each of these about it here so I can track it?
(I can open one for you but you may prefer to get updates about it - if
you'd prefer I just open one reply and let me know):
https://github.com/lathiat/avahi/issues

Regards,
Trent
@lathiat
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
This is for avahi-0.6.31-26.1.x86_64 from OpenSuSE "Leap" 42.1. I've
written a set of simple test scripts that check if daemons are
functioning, restarting them if not. The one for avahi-daemon basically
does: (illustrated executing on host kermit)
No RR's are returned and the query times out. In syslog I see
"Received packet from invalid interface." If I ask about Kermit but
executing on any different host, the correct content is returned, and
similarly for all pairs of hosts on my net: a unicast query to the
execution host yields nothing, but to a different host is answered
reliably. Every query fails/succeeds equally, e.g. an AAAA record, or
asking for the PTR at _ssh._tcp.local. It fails/succeeds equally when
the IPv4 or IPv6 address of the server is used. Multicast queries to
224.0.0.251 and ff02::fb are answered even from the execution host.
I tracked this down to (source)/avahi-core/server.c ; see
dispatch_packet() in that file. The AvahiIfIndex (believed same as
/sys/class/net/${IFC}/ifindex) is 1, identifying lo (loopback) on my
machine, and its i->announcing flag is zero (as it should be). But the
contingency at the start of this subroutine causes packets received from
non-announcing interfaces to be tossed with the "invalid interface"
message, explaining the symptom. But I don't see how multicast packets
escape the ax.
I wish a distinction could be made between interfaces (e.g. lo) whose
address should not be announced, versus deny-interfaces members.
There's a second issue which I should mention, though it may be hard to
fix. On my net, Linux boxes generally have a fixed IP gotten by DHCP,
plus a RFC 4862 address (prefix + EUI-64). Avahi-daemon lets the kernel
pick which one to send from. "dig", but not Perl's Net::DNS::Resolver,
rejects packets from other than the address it sent the (unicast) query
to, and so from half the machines, Avahi responses are rejected noisily
by "dig" but are functional on other software. I wish that avahi-daemon
would respond to unicast queries (of course not multicast) using the
source address in the query packet.
/etc/avahi/avahi-daemon.conf follows, with comments removed. Changes
from (source>/avahi-daemon/avahi-daemon.conf are noted.
[server]
use-ipv4=yes
use-ipv6=yes # Local mod, turned on
allow-interfaces=wlan0 # Local mod to explicitly allow wlan0
ratelimit-interval-usec=1000000
ratelimit-burst=1000
[wide-area]
enable-wide-area=yes
[publish]
publish-a-on-ipv6=yes # Local mod, turned on
[reflector]
# no reflector
[rlimits]
rlimit-core=0
rlimit-data=4194304
rlimit-fsize=0
rlimit-nofile=768
rlimit-stack=4194304
rlimit-nproc=3
- --
Web: http://www.math.ucla.edu/~jimc (q.v. for PGP key)
-----BEGIN PGP SIGNATURE-----
iQEzBAEBCAAdFiEEwCO3Ffd4f3UN9nvKddigLE9RfKkFAlkXWG0ACgkQddigLE9R
fKkRpwgAnKNuIOiIABXHFV18dHNb3PSWdRdxCUJ8i8AOQspVw0fl/z7jjtOryuWn
BqqLUdZGBpPXLTLX6h7V9cBwClJE3bx6xyoMR1aXgRIrZnONtoSY/OhSP01GBrq/
JC6PIqrodIePWl/1OQm9NkiotILFFMzl/Y9exXxqcQyExOmZM33BKvwzu7GIBAIf
nUj1SnBVV7YNoXgv0IJMiL5nDcupwXlfCYbbyXivJyvpGf+T/5HNBxBXjV3K1A+b
cRhIShbILFtbB6wYh27A2+rQaTlRqC60jdg4iKqXe2zuSdknTklPHepTN6y6Zyni
dAWeYbfXY68zAXcj9IPpylxbrDro+g==
=fNbk
-----END PGP SIGNATURE-----
_______________________________________________
avahi mailing list
https://lists.freedesktop.org/mailman/listinfo/avahi
Loading...