From alex_chen at claris.com Tue Sep 8 20:44:17 2020 From: alex_chen at claris.com (Alex Chen) Date: Tue, 08 Sep 2020 13:44:17 -0700 Subject: [avahi] Crash in avahi-common Message-ID: <5F64E9BC-61D1-4C47-B9C2-A9C2AE2F099E@claris.com> Hi, We have experienced several crashes in Avahi, 0.6.31, running CentOS 7.8. The crash dump is in avahi library. This is what I see from gdb. =============== (gdb) bt #0 0x00007f5d83300387 in raise () from /lib64/libc.so.6 #1 0x00007f5d83301a78 in abort () from /lib64/libc.so.6 #2 0x00007f5d832f91a6 in __assert_fail_base () from /lib64/libc.so.6 #3 0x00007f5d832f9252 in __assert_fail () from /lib64/libc.so.6 #4 0x00007f5d7c54dc0e in avahi_simple_poll_dispatch () from /lib64/libavahi-common.so.3 #5 0x00007f5d7c54debd in avahi_simple_poll_loop () from /lib64/libavahi-common.so.3 #6 0x00007f5d7c54df84 in thread () from /lib64/libavahi-common.so.3 #7 0x00007f5d842c7ea5 in start_thread () from /lib64/libpthread.so.0 #8 0x00007f5d833c88dd in clone () from /lib64/libc.so.6 =============== I downloaded the source code of that version and annotated the stack far,es. There are four asserts in avahi_simple_poll_dispatch(). It is hard to tell which one triggers the accept. The first one does not seem to be an issue since 'assert(s)' is also called in avahi_simple_poll_loop() in frame #5. Any help is appreciated. Thanks Alex =========== #0 0x00007f5d83300387 in raise () from /lib64/libc.so.6 #1 0x00007f5d83301a78 in abort () from /lib64/libc.so.6 #2 0x00007f5d832f91a6 in __assert_fail_base () from /lib64/libc.so.6 #3 0x00007f5d832f9252 in __assert_fail () from /lib64/libc.so.6 avahi-common/simple-watch.c int avahi_simple_poll_dispatch(AvahiSimplePoll *s) { AvahiTimeout *next_timeout; AvahiWatch *w; assert(s); assert(s->state == STATE_RAN); s->state = STATE_DISPATCHING; /* We execute only on callback in every iteration */ /* Check whether the wakeup time has been reached now */ if ((next_timeout = find_next_timeout(s))) { if (next_timeout->expiry.tv_sec == 0 && next_timeout->expiry.tv_usec == 0) { /* Just a shortcut so that we don't need to call gettimeofday() */ timeout_callback(next_timeout); goto finish; } if (avahi_age(&next_timeout->expiry) >= 0) { /* Timeout elapsed */ timeout_callback(next_timeout); goto finish; } } /* Look for some kind of I/O event */ for (w = s->watches; w; w = w->watches_next) { if (w->dead) continue; assert(w->idx >= 0); assert(w->idx < s->n_pollfds); if (s->pollfds[w->idx].revents != 0) { w->callback(w, w->pollfd.fd, s->pollfds[w->idx].revents, w->userdata); goto finish; } } finish: s->state = STATE_DISPATCHED; return 0; } #4 0x00007f5d7c54dc0e in avahi_simple_poll_dispatch () from /lib64/libavahi-common.so.3 avahi-common/simple-watch.c int avahi_simple_poll_loop(AvahiSimplePoll *s) { int r; assert(s); for (;;) if ((r = avahi_simple_poll_iterate(s, -1)) != 0) if (r >= 0 || errno != EINTR) return r; } int avahi_simple_poll_iterate(AvahiSimplePoll *s, int timeout) { int r; if ((r = avahi_simple_poll_prepare(s, timeout)) != 0) return r; if ((r = avahi_simple_poll_run(s)) != 0) return r; if ((r = avahi_simple_poll_dispatch(s)) != 0) return r; return 0; } #5 0x00007f5d7c54debd in avahi_simple_poll_loop () from /lib64/libavahi-common.so.3 avahi-common/thread-watch.c static void* thread(void *userdata){ AvahiThreadedPoll *p = userdata; sigset_t mask; /* Make sure that signals are delivered to the main thread */ sigfillset(&mask); pthread_sigmask(SIG_BLOCK, &mask, NULL); pthread_mutex_lock(&p->mutex); p->retval = avahi_simple_poll_loop(p->simple_poll); pthread_mutex_unlock(&p->mutex); return NULL; } #6 0x00007f5d7c54df84 in thread () from /lib64/libavahi-common.so.3 #7 0x00007f5d842c7ea5 in start_thread () from /lib64/libpthread.so.0 #8 0x00007f5d833c88dd in clone () from /lib64/libc.so.6 -------------- next part -------------- An HTML attachment was scrubbed... URL: From philipp_subx at redfish-solutions.com Sat Sep 26 16:16:16 2020 From: philipp_subx at redfish-solutions.com (Philip Prindeville) Date: Sat, 26 Sep 2020 10:16:16 -0600 Subject: [avahi] avahi won't use P2P interface despite being told In-Reply-To: <1D2CF148-4A0D-4C27-96C7-86430F0336E8@kfu.com> References: <74BFDFAF-2BE6-4061-8710-47A005C7C8ED@kfu.com> <1D2CF148-4A0D-4C27-96C7-86430F0336E8@kfu.com> Message-ID: What does ?multicast? mean on a link that?s inherently unicast by nature of being point-to-point? This shouldn?t be required. See: https://github.com/lathiat/avahi/issues/305 > On May 30, 2020, at 12:32 PM, Nick Sayer wrote: > > Never mind. I needed to do > > ip link set [interface] multicast on > > That fixed it. > > >> On May 30, 2020, at 11:10 AM, Nick Sayer wrote: >> >> I have avahi-daemon 0.7 running on a raspberry pi. I have set up a GRE tunnel to another pi and wish to have avahi on both ends of the tunnel reflect mDNS across the tunnel. >> >> I?ve set allow-point-to-point=yes and enable-reflector=yes, but when I attempt to run avahi-daemon ?debug, I see it making no attempt to probe or discover the point to point interface at all. >> >> I did find mdns-repeater on the Internet, and that does work, except that the two hosts on either end of the GRE tunnel won?t participate since they don?t see transmitted traffic from mdns-repeater and, of course, they?re not listening on the tunnel. >> >> Why doesn?t allow-point-to-point=yes actually work? > > _______________________________________________ > avahi mailing list > avahi at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/avahi From philipp_subx at redfish-solutions.com Sat Sep 26 17:24:16 2020 From: philipp_subx at redfish-solutions.com (Philip Prindeville) Date: Sat, 26 Sep 2020 11:24:16 -0600 Subject: [avahi] Code review request on PR #306 Message-ID: <9D7C3A74-BB19-47DE-8044-B18E34D7EF5C@redfish-solutions.com> Hi, I was reviewing the logic where avahi-daemon requires the multicast bit (IFF_MULTICAST) be set on the interface of point-to-point tunnels, where a point-to-point connection is by definition unicast (in that the packets can only ever go to a single recipient, i.e. the node at the other end of the tunnel). Seems it?s previously been an issue: https://lists.freedesktop.org/archives/avahi/2020-May/thread.html#2538 Anyway, the change is trivial: https://github.com/lathiat/avahi/pull/306 It?s a relatively simple change I was hoping to get reviewed. If the interface is: (1) loopback OR (2) multicast OR (3) point-to-point AND allow-point-to-point is enabled then the interface should be used. I?ve run both the previous and the current version of the PR in production with GRE-over-IPsec tunnels and both work in those cases. This patch is useful when you?re using an IPsec manager that doesn?t allow you to customize tunnel bring-up through scripts where you can simply flag the tunnel as ?ip link set multicast on dev $IFNAME?? but that, as the original issue suggests, is the wrong mindset. Requiring the multicast flag (i.e. ?group delivery? capable) on a point-to-point interface (which is inherently limited to a ?group of one?, i.e. not a ?group? at all) is thinking about this wrong. I have a few scenarios where I?m using mDNS in VPN scenarios (where the tunneling protocol of choice is ESP) and this should work transparently. Thanks, -Philip