Hi Taz,
thanks for bringing this up.
Unfortunately, I don't fully understand your use case. If your discovery
protocols operate with TTL=1, then they are restricted to your local
subnet and cannot traverse any router. Hence, a Multicast Proxy, which
is a router function, won't be of any use.
For your deployment, this would simply mean to put all your devices from
the same discovery group into one flat VLAN. Things should work then
without any router configuration.
Best,
Thomas
On 09/05/2020 15:19, Taz Motor wrote:
A few discovery protocols (most prominently mDSN DNS-SD and UPnP SSDP)
that are used by end consumer products are using multicast for
transport. Unfortunately when setting up a smart home, you cannot ignore
those discovery protocols, because often you have no control how the
proprietary products discover their peer nodes.
Also, if you set up a smart home, you will have a non-negligible number
of nodes with untrustworthy firmware that you may want to segregate from
you trusted nodes, and possibly even from the internet. This leads you
to a segmented network using VLANs. There are several ways of doing it.
For this post I would like to focus only on a setup like this:
(1) 1x OpenWRT router (not using AP functionality) accessing the VLANs
via a trunked interface to a managed switch (e.g. Ubiquity Unify Switch),
(2) with NO interface bridging on the side of OpenWRT, hence IGMP
snooping disabled. (3) Let us also assume that all multicast senders and
receivers are on wired ethernet connections, so there is NO need to
convert multicast traffic to directed unicast datastreams for better
WiFi performance.
The main challenge is getting the multicast discovery datagrams form the
sender's subnet to the subnets containing relevant receivers:
(4) these UDP multicast datagrams usually have a TTL of 1, and
(5) we assume that we have no way of influencing that by configuring the
sender (e.g. a Logitech Harmony Hub, or a Sony PlayStation).
For sender appliances using mDNS DNS-SD there is a simple solution
available: AVAHI with enabled "reflector" (think "proxy") will pick up
the multicast packets destined to port 5353 and re-transmits them on the
other subnets. This solves the TTL=1 problem elegantly. Unfortunately
AVAHI is specifically targeting mDNS and does not work for UPnP SSDP
datagrams (UDP port 1900).
Therefore I am looking for a more general solution, possible not
involving datagram mangling using firewall rules to increase the TTL by 1.
Is it possible to use mcproxy for this use case?
--
You received this message because you are subscribed to the Google
Groups "Multicast Proxy" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to [email protected]
<mailto:[email protected]>.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/multicast-proxy/c418ced6-02fe-430e-a069-80e2aba747a7%40googlegroups.com
<https://groups.google.com/d/msgid/multicast-proxy/c418ced6-02fe-430e-a069-80e2aba747a7%40googlegroups.com?utm_medium=email&utm_source=footer>.
--
Prof. Dr. Thomas C. Schmidt
° Hamburg University of Applied Sciences Berliner Tor 7 °
° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany °
° http://inet.haw-hamburg.de/members/schmidt Fon: +49-40-42875-8452 °
--
You received this message because you are subscribed to the Google Groups "Multicast
Proxy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web, visit
https://groups.google.com/d/msgid/multicast-proxy/48d25c50-8be2-0e1d-d5d9-f655dcdc500f%40haw-hamburg.de.
