search

haesbaert / mdnsd

Mdns daemon for OpenBSD.
www.haesbaert.org/openmdns
136 stars 27 forks source link

OpenBSD 6.1, mdnsd not receiving multicast packets? #22

Closed nbriggs closed 7 years ago

nbriggs commented 7 years ago

I didn't have this problem on FreeBSD 11.0, but on OpenBSD 6.1 despite mdnsd's doing the proper IP_ADD_MEMBERSHIP, it doesn't receive any multicast packets. If you run "tcpdump -i port 5353" then the promiscuous mode will enable it to see the packets, but with "tcpdump -p -i port 5353" you don't see them. Hosts that cache the initial packets sent will see the system for a while, but then the cache entries time out and further queries are not answered.

I could easily believe this is something I've done wrong in my OpenBSD configuration, but I don't know what...

multicast=YES in /etc/rc.conf.local

ifconfig tl0 tl0: flags=208843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,AUTOCONF6> mtu 1500 lladdr 00:80:5f:bd:53:49 index 1 priority 0 llprio 3 groups: egress media: Ethernet autoselect (100baseTX full-duplex) status: active inet6 fe80::280:...%tl0 prefixlen 64 scopeid 0x1 inet6 2602:24a:... prefixlen 64 autoconf pltime 604764 vltime 2591964 inet6 2602:24a:... prefixlen 64 autoconf autoconfprivacy pltime 58831 vltime 577557 inet 192.168.42.88 netmask 0xffffff00 broadcast 192.168.42.255

./mdnsd -d tl0

malloc() warning: unknown char in MALLOC_OPTIONS malloc() warning: unknown char in MALLOC_OPTIONS startup cache_insert: (new, cleaned up) (0x86ab1400) pigeon [tl0:00:80:5f:bd:53:49]._workstation._tcp.local (SRV) cache_insert: (new, cleaned up) (0x840f3400) pigeon [tl0:00:80:5f:bd:53:49]._workstation._tcp.local (TXT) using iface tl0 index 1 cache_insert: (new, cleaned up) (0x840f6000) pigeon.local (A) cache_insert: (new, cleaned up) (0x86aac000) 88.42.168.192.in-addr.arpa (PTR) cache_insert: (new, cleaned up) (0x86ab1800) pigeon.local (HINFO) opened raw socket with kernel on fd 5 mdns sock bound to 0.0.0.0:5353 if_fsm: event 'UP' resulted in action 'START' and changing state for interface tl0 from 'DOWN' to 'ACTIVE'

nbriggs commented 7 years ago

I've solved this problem. Turns out it was a bug in the OpenBSD kernel in "if_tl.c" -- the calculation of the hash for the multicast addresses to be recognized that gets programmed into the ThunderLAN chip was incorrect (an issue with signed vs. unsigned characters). This meant that the mdns code would send out its information, which lasted for a while, but since it never saw any further messages on the multicast group things eventually aged out. If you try to debug it with tcpdump it all starts to work because the interface goes into promiscuous mode (unless you use -p) and then it sees the messages. I believe that this is only an issue on the "tl" interfaces.

haesbaert commented 7 years ago

Thanks for checking this in, and sorry for the late response.