mDNS packets send to wrong interface

Expected Behavior

When running homebridge on router, mDNS packets should send to local network interface (like eth1) rather than wan interface (like eth0) So iDevices can add homebridge to homekit

Current Behavior

All mDNS packets send to wan device iPhone cannot find any accessory after scan qrcode

Steps to Reproduce (for bugs)

On my router, i run these commands while homebridge is running:

ifconfig output

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.2  netmask 255.255.255.0  broadcast 192.168.1.255
        inet6 fe80::2e0:4dff:fe71:181  prefixlen 64  scopeid 0x20<link>
        ether 00:xx:xx:xx:xx:81  txqueuelen 1000  (Ethernet)


eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.42.1  netmask 255.255.254.0  broadcast 192.168.42.255
        inet6 fe80::2e1:4dff:fe71:17a  prefixlen 64  scopeid 0x20<link>
        ether 00:xx:xx:xx:xx:7a  txqueuelen 1000  (Ethernet)

(wan device: eth0, lan device: eth1)

sudo tcpdump -n udp dst port 5353 -i eth0 output

listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
17:18:10.054717 IP 192.168.1.2.5353 > 224.0.0.251.5353: 0*- [0q] 7/0/0 PTR Homebridge-3B00._hap._tcp.local., SRV CC_XX_XX_XX_XX_XX.local.:51826 0 0, TXT "md=Homebridge" "pv=1.0" "id=CC:xx:xx:xx:xx:xx" "c#=2" "s#=1" "ff=0" "ci=2" "sf=1" "sh=o1M/HA==", A 192.168.1.2, AAAA fe80::2e0:4dff:fe71:181, A 192.168.42.1, AAAA fe80::2e1:4dff:fe71:17a (448)
.....

sudo tcpdump -n udp dst port 5353 -i eth1 output

listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes
<nothing here at all>

Versions

• Homebridge: 0.4.44
• Node: v8.11.3
• OS: Debian 9, x86_64

Homebridge Log / Command Output

............qrcode and some plugin loaded output..........
[2018-8-4 17:02:37] [Homebridge Info] is listening on: http://192.168.1.2:9876
[2018-8-4 17:02:37] [Homebridge Info] is listening on: http://192.168.42.1:9876
[2018-8-4 17:02:37] Homebridge is running on port 51826.

[StoneMoe]

Use config mdns.interface can solve this issue by forcing multicast lib bind to specify interface.

example:

{
    "mdns": { "interface": "192.168.42.1" },  // here
    "bridge": {
        "name": "...",
        "username": "...",
        "port": ...,
        "pin": "..."
    },
    "description": "....",
    "accessories": [
....
    ],
    "platforms": [
....
}

[evanpurkhiser]

I know this doesn’t contribute to the conversation, but I really just wanted to say thank you @StoneMoe. I spent two hours trying to figure this out and had no idea of the existence of the mdns configuration.