I am using mcproxy this way to bridge SSDP discovery across vlans on OpenWrt. It works.
Jeff. On Wednesday, June 3, 2020 at 9:16:27 AM UTC-7 [email protected] wrote: > 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] >> > <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 >> <+49%2040%20428758452> ° >> >> -- 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/7c74e0a5-8c72-472d-8bc2-7150c30e4aa5n%40googlegroups.com.
