geekman / mdns-repeater Goto Github PK

Hello,
as more and more internet uplinks includes IPv6 with prefix delegation, would be great if the repeater supports IPv6 too.
Thanks
Thomas

Because I'm not sure of the right set of fixes, I'm filing this issue with each of:
Google Chromecast/Home Team (via email),
https://github.com/jstasiak/python-zeroconf,
https://github.com/kennylevinsen/mdns-repeater,
https://github.com/home-assistant/plugin-multicast, and
https://github.com/home-assistant/core

I just spent the weekend tracking this down as I apparently started using mdns-repeater
unwittingly due to a change in HomeAssistant's hass.io and its new
multicast plugin
(https://github.com/home-assistant/plugin-multicast). That resulted in
a revival of some terrible instability in my 30+ Google ChromeCast
Audio (CCA) devices in my home -- the problem had gone away a couple
months ago and I'd attributed it to IGMP issues, but I peeled the
onion and this is what I found.

BUG #1 CHROMECAST AUDIO DEVICE PROCESS CRASHES ENDING mDNS:

The mDNS announcing process of Google Chromecast Audios (a
discontinued product, unfortunately) dies when triggered by the steps
below using mdns-repeater and python zeroconf (via Home Assistant in my case).

The CCA crash manifests itself by the multicast messages announcing
the CCA and its audio groups stopping appearing. E.g., if you do

tcpdump -npi eno1 port 5353 and host [CCA_IP]

you'll see a couple of PTR responses coming from the devices every 10
seconds, announcing something like:

Chromecast-Audio-dc.a.................f._googlecast._tcp.local: type TXT, class IN, cache flush

when the set of steps below happens, these announcements end until either:

1. the CCA reboots (power cycle); or

2. the CCA is forced to switch to a new WAP; e.g., I have a script
   that forces a client to reconnect to the WAP in order to kick this
   mDNS announcing process back on.

When those announcements cease, the Google Home app on Android stops
showing "Play Music" links under that device in the display. HOWEVER,
there is a per-physical-WAP (based off the MAC of the WAP, not SSID,
so it is not shared across multiple mesh-networked WAPs on the same
SSID) cache for Google Home, so you won't see the problem happen
immediately. You instead, have to go to another room, ensure the phone
is connected to a new WAP, and then see that "Play Music" will no
longer show up for that device.

It's worthing noting that the TCP socket interface to each ChromeCast Audio
device is still working after the MDNS announcing process has died. E.g.,
you can still play music and control the device via TCP APIs, you just
can't discover the device via mDNS.

BUG #1 SUMMARY - HIGH SEVERITY but probably NO FIX: Google ChromeCast
Audio must not crash due to bad network data. (But this probably won't
get fixed since Google Home/Mini do not have the bug and the CCA is a
discontinued product.)

BUG #2 PYTHON ZEROCONF SHOULD NOT SEND HUGE PACKETS

I have 30+ ChromeCast Audio devices and over 80+ Google casting
devices. A query response to _googlecast._tcp.locl. results in
a response that's almost 4KB, far larger than the 1500 MTU on
most ethernet switches. E.g., if I modify examples/browser.py
to interrogate like so:

browser = ServiceBrowser(zeroconf, "_googlecast._tcp.local.", handlers=[on_service_state_change])

zeroconf will then publish those 4KB mDNS responses. They, of
course, get IP fragmented and that seems to be find when multicasting
directly to the CCAs and other devices. However, RFC 6762
(https://tools.ietf.org/html/rfc6762) section 17 states some
requirements for Multicast DNS Message Size, and the fourth paragraph reads:

"A Multicast DNS packet larger than the interface MTU, which is sent
using fragments, MUST NOT contain more than one resource record."

Larger than the interface MTU seems to me to mean that these Responses
must limit themselves to no more than 1500 octets (except in the
special case of a long single record that's too big). That's not the
issue here -- the responses causing the crash are, e.g., 59 Resource
Records (RR) in the answer (not a single long one).

For whatever reason, that problem alone is not causing the ChromeCast
Audios to crash, but I strongly suspect that fixing this problem would
fix the stack. I believe these MUST be broken up into separate UDP
packets of length <= 1500 (the interface MTU) at the application layer
(rather than using IP fragmentation).

You can reproduce this using avahi-publish to create lots of records in a
subdomain and then browsing that subdomain. The total length of the
DNS records should exceed 2KB (for good measure to be sure it's
big enough).

BUG #2 SUMMARY - MEDIUM SEVERITY AND STRAIGHTFORWARD FIX: python
zeroconf MUST adhere to RFC 6762.

BUG #3 MDNS-REPEATER SOMEHOW TICKLES BUG #1 WHEN PRESENTED WITH MDNS IP FRAGMENTS

I've not investigated this thoroughly, but I suspect it's either due
to some kind of UDP storm due to a cycle that crashes that CCAs
because of the fragmentation, or some kind of packet rewriting.

The only other open issue on home-assistant/plugin-multicast seems
possibly relevant
(home-assistant/plugin-multicast#1) and
jesserockz's note at the end is worth understanding/trying. I don't
think the mdns-repeater code should be mirroring all the interfaces,
so if it is, that's a bug.

Note that in the configuration where I can reproduce this,
mdns-repeater is running inside Home Assistant's hass.io plugin called
the home-assistant/plugin-multicast

I work around it by running a shell inside that docker environment and
changing the run command to comment out the running of mdns-repeater
(since just docker stop-ping that container results in the hassio
supervisor restarting the container).

It may be worth noting that the machine on which hassio has many network interfaces:

$ ifconfig # output follows
docker0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
eno1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
eno2: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
enp2s0f0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
enp2s0f1: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
hassio: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
veth0ac5dfe: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
veth0ff2059: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
veth1b05ec4: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
veth3003e6f: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
veth347b241: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
veth54a968f: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
veth748acbe: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
vethc5fab43: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
vethedd7c47: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
virbr0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500

BUG #3 SUMMARY - UNCERTAIN SEVERITY AND FIX. Confirm it's behaving
as expected when there are multiple interfaces and in the presence
of UDP packets undergoing IP fragmentation.

Summary: I propose fixing python-zeroconf as the quickest and easiest
change, and ideally someone more in tune with what homeassistant is
trying to do with mdns-repeater could figure out the right fix to
mdns-repeater and/or the way the multicast plugin is configured.

Let me know what more information you need.

The original author has moved the code from bitbucket (https://bitbucket.org/geekman/mdns-repeater) to github (https://github.com/geekman/mdns-repeater).

I had a lot of trouble finding this fork since the bitbucket link from which this was forked is invalid and there is no connection between this fork and the (now existing) repo in Github, mentioned above.

If possible, this should somehow be fixed so there's proper documented lineage of the code.

The correct IP multicast address for multicast DNS is 224.0.0.251. It's incorrect in the readme file.

Hi

Can you please use a permissive license like MIT?

Thank you

Poking around a bit, this looks like this is the official repository for mdns-repeater. Please correct me if I'm wrong, I saw a couple other copies of it floating around in github

I've been splitting my home network into multiple VLANs for security. I use a Unifi Security Gateway (USG) as a router. USGs offer mdns-repeater to rebroadcast mDNS packets between VLANs. I ran into an issue with mdns-repeater on the USG, and after some digging I think I've finally tracked down the problem: https://community.ui.com/questions/mDNS-repeater-doesnt-work-but-mDNS-reflector-does/646a3583-a510-4296-9b46-84c10bbe94be

The mDNS packets coming from mdns-repeater have an IP TTL of 1, when it's supposed to be 255: https://www.wireshark.org/lists/wireshark-bugs/201002/msg00513.html

All Multicast DNS responses (including responses sent via unicast) SHOULD be sent with IP TTL set to 255.

mdns-repeater should explicitly set an IP TTL of 255

I'm going to take a crack at resolving this, unless there are any objections

Hi there,

Thanks for the great tool, I can finally use mDNS over Wiregurad VPN!
I'm not sure I quite understand how I can install it though.

I cloned this repo into my RPi, then ran "make", which created a new folder with the mdns-repeater tool in it.
I ran "./mdns-repeater eth0 wg0", nothing happens. But when I ran "./mdns-repeater -f eth wg0", it opens the debugger and the repeating actually works.

Am I doing it right? Should I run it manually as a service/daemon or is my installation wrong?

I downloaded and compiled on linux the current
version of mdns-repeater (february 14 2022).

I will mention that the current setup is working:
the apple devices can see each other between the
two networks, but I observed with tcpdump that
the anomaly described here appears.

I ran the command "mdns-repeater eth0 eth0.600"

This is the system setup:

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 8c:16:45:72:cd:3f brd ff:ff:ff:ff:ff:ff
inet 10.81.128.10/24 brd 10.81.128.255 scope global eth0
valid_lft forever preferred_lft forever
3: eth0.600@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 8c:16:45:72:cd:3f brd ff:ff:ff:ff:ff:ff
inet 10.81.130.10/32 scope global eth0.600
valid_lft forever preferred_lft forever

Since the system has only one network card, I
configured a vlan to act as a bridge.
IP 10.81.128.10 is configured on the eth0 card
(packets are not tagged), while 10.81.130.10 is
configured on vlan 600 (packets are tagged).
The switch to which the system is connected is
configured accordingly.

As you can see below, tcpdump reports the packet
with source 10.81.130.69 (vlan600) being transmitted
with source 10.81.128.10 on the eth0 network card,
and then it is retransmitted on vlan600 with source
10.81.130.10

This happens only for packets that originate from
the tagged vlan600. Packets that source from the
eth0 card are not duplicated back to the eth0 card.

Is this the expected behavior?

Marco

15:09:22.586129 3c:22:fb:07:63:de > 01:00:5e:00:00:fb, ethertype 802.1Q (0x8100), length 426: vlan 600, p 0, ethertype IPv4 (0x0800), (tos 0x0, ttl 255, id 36006, offset 0, flags [none], proto UDP (17), length 408)
10.81.130.69.5353 > 224.0.0.251.5353: 0*- [0q] 2/0/6 Covi Rosc._device-info._tcp.local. TXT "model=MacBookPro15,4" "ecolor=157,157,160", _companion-link._tcp.local. PTR Covi Rosc._companion-link._tcp.local. (380)

15:09:22.586212 8c:16:45:72:cd:3f > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 422: (tos 0x0, ttl 255, id 22751, offset 0, flags [DF], proto UDP (17), length 408)
10.81.128.10.5353 > 224.0.0.251.5353: 0*- [0q] 2/0/6 Covi Rosc._device-info._tcp.local. TXT "model=MacBookPro15,4" "ecolor=157,157,160", _companion-link._tcp.local. PTR Covi Rosc._companion-link._tcp.local. (380)

15:09:22.586223 8c:16:45:72:cd:3f > 01:00:5e:00:00:fb, ethertype 802.1Q (0x8100), length 426: vlan 600, p 0, ethertype IPv4 (0x0800), (tos 0x0, ttl 255, id 62146, offset 0, flags [DF], proto UDP (17), length 408)
10.81.130.10.5353 > 224.0.0.251.5353: 0*- [0q] 2/0/6 Covi Rosc._device-info._tcp.local. TXT "model=MacBookPro15,4" "ecolor=157,157,160", _companion-link._tcp.local. PTR Covi Rosc._companion-link._tcp.local. (380)

PS: tcpdump capture is taken on the eth0

Hi Kenny,

Do you think it is possible to extend the forwarded multicast range to the whole 224.0.0.0/4 subnet - or at least to include 239.255.255.250 to make SSDP work; and how difficult would it be to modify mdns-repeater to do this?

Thanks,
István

Is is possible to get this running on an ASUS router? I've ran into the issue of not being able to control multicast stuff while tunnelling into my ASUS RT-AX58U and wasn't aware it was a full blown limitation.

Hi, I really like this great piece of software, but unfurtunately I cannot get it running as a service without failing after a while. I am using the following mdns-repeater.service file:

[Unit]
Description=mDNS Repeater
Wants=network-online.target
After=network-online.target

[Service]
Type=simple
ExecStart=/home/user/mdns-repeater/mdns-repeater eth0 tun0

[Install]
WantedBy=multi-user.target

Problem is that:

• When I start the service with "ExecStart=/home/user/mdns-repeater/mdns-repeater eth0 tun0" (without attribute "-f"), Debian reports the service as "inactive (dead)" when I check the service's status;
• When I start the service with "ExecStart=/home/user/mdns-repeater/mdns-repeater eth0 tun0 -f" (with attribute "-f") it will crash after a while and won't restart automatically as Debian complains about "start request repeated too quickly".

Could you please provide me with the best practice settings for an mdns-repeater.service in Debian that will make mdns-repeater run as a stable service? Thanks a lot!

Hi,

I tried making this project locally and am hit with the errors if I installed Mercurial:

abort: no repository found in '/home/cj/workspace/mdns-repeater' (.hg not found)!
abort: no repository found in '/home/cj/workspace/mdns-repeater' (.hg not found)!

I do not know if this is an issue from moving the project to git since I have never used Mercurial.

Without Mercurial installed, I get the following:

/bin/sh: 1: hg: not found
/bin/sh: 1: hg: not found
cc -s  mdns-repeater.o   -o mdns-repeater

Seems like it did compile, however.

Its possible to use in blacklist just the interface?

The function argument sig in mdns_repeater_shutdown is unused and raises a warning with -Wextra.

This can e.g. be fixed by explicitly casting the argument to void:

static void mdns_repeater_shutdown(int sig) {
    shutdown_flag = 1;
}

would become

static void mdns_repeater_shutdown(int sig) {
    (void)sig;
    shutdown_flag = 1;
}

Thank you for maintaining mdns-repeater! 😊