avahi / avahi

Avahi - Service Discovery for Linux using mDNS/DNS-SD -- compatible with Bonjour

Home Page:http://www.avahi.org

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

A lot of annoying sendmsg() to ff02::fb (iface #1) failed: Network is unreachable is generated

pemensik opened this issue · comments

It seems this is related to issue #125 implementation. I think it is failing, because destination address used on loopback lo interface does not have MULTICAST flag. Therefore sending multicast destination packet cannot succeed.

This could in theory be fixed by using dest address as our own address. But it does not make sense to send packets to our own loopback addresses, unless we expect other mdns stacks are listening there as well.

(gdb) bt
#0  avahi_send_dns_packet_ipv6 (fd=12, interface=1, p=0x4717e0, src_address=0x432cdc, dst_address=0x0, dst_port=0)
    at socket.c:581
#1  0x00007ffff7f75273 in avahi_interface_send_packet_unicast (i=0x432ca0, p=0x4717e0, a=0x0, port=0) at iface.c:604
#2  0x00007ffff7f75303 in avahi_interface_send_packet (i=0x432ca0, p=0x4717e0) at iface.c:611
#3  0x00007ffff7f889b8 in append_known_answers_and_send (s=0x4335d0, p=0x4717e0) at query-sched.c:269
#4  0x00007ffff7f88b44 in elapse_callback (e=0x4632d0, data=0x463280) at query-sched.c:310
#5  0x00007ffff7f72a2b in expiration_event (timeout=0x430190, userdata=0x436970) at timeeventq.c:94
#6  0x00007ffff7fba561 in timeout_callback (t=0x430190) at simple-watch.c:447
#7  0x00007ffff7fba972 in avahi_simple_poll_dispatch (s=0x42d490) at simple-watch.c:570
#8  0x00007ffff7fbaae9 in avahi_simple_poll_iterate (s=0x42d490, timeout=-1) at simple-watch.c:605
#9  0x0000000000409d85 in run_server (c=0x427a40 <config>) at main.c:1279
#10 0x000000000040aa13 in main (argc=2, argv=0x7fffffffe368) at main.c:1708

(gdb) frame 2
#2  0x00007ffff7f75303 in avahi_interface_send_packet (i=0x432ca0, p=0x4717e0) at iface.c:611
611	    avahi_interface_send_packet_unicast(i, p, NULL, 0);

(gdb) p *i
$4 = {monitor = 0x431ed0, hardware = 0x437030, interface_next = 0x432330, interface_prev = 0x433680, 
  by_hardware_next = 0x432330, by_hardware_prev = 0x0, protocol = 1, announcing = 1, local_mcast_address = {
    proto = 1, data = {ipv6 = {address = '\000' <repeats 15 times>, "\001"}, ipv4 = {address = 0}, data = ""}}, 
  mcast_joined = 1, cache = 0x433150, query_scheduler = 0x4335d0, response_scheduler = 0x4335a0, 
  probe_scheduler = 0x433610, addresses = 0x44aac0, announcers = 0x460050, queriers_by_key = 0x432d40, 
  queriers = 0x46b9d0}

(gdb) p *i->hardware
$5 = {monitor = 0x431ed0, hardware_next = 0x0, hardware_prev = 0x4377d0, name = 0x42da30 "lo", index = 1, 
  flags_ok = 1, mtu = 65536, mac_address = "\000\000\000\000\000\000,\"parameters\":{\"userName\":", 
  mac_address_size = 6, entry_group = 0x0, ratelimit_begin = {tv_sec = 1706365099, tv_usec = 11741}, 
  ratelimit_counter = 1, interfaces = 0x432ca0}

Strange is it has mcast_joined==1 on interface structure, which is very likely wrong. It seems to me we should detect if interface has MULTICAST feature in ip link and skip attempts to send multicast to this interface. We want services there, but not multicast usage.

It should be noted this happens when --debug is used on command line.