Hi Thomas, I could do that but I will not. I have a security segregation between the IoT network and the servers. The integration platform is in the server network. some IoT component wants to find something using SSDP that the integration platform offers.
Of course a proxy could help here. Look at Avahi in reflector mode. But Avahi does not proxy SSDP. regards Am Sonntag, 10. Mai 2020 01:38:11 UTC+2 schrieb Thomas Schmidt: > > 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] <javascript:> > > <mailto:[email protected] <javascript:>>. > > 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/ca1944b0-ff65-4f2a-a75a-1757f6ed14d4%40googlegroups.com.
