Manually configuring the HmIPW DRAP

[jkunczik]

Hello all,

I want to move my RasperryMatic from my IOT network to a more secure DMZ. However, I had to find out that the discovery protocol eQ3 implemented uses the multicast IPs 224.0.0.1 and 224.0.0.120. Unfortunately, 224.0.0.0/24 seems to be non-routable (see this issue), even using smcroute and TTL mangling.

Is there a way to set up multicast routing for the Homematic IP discovery protocol that I didn't find after two days of browsing the internet, or is there a possibility to manually configure the connection between a CCU3 and a DRAP to allow for network segregation?

[jens-maus]

Is there a way to set up multicast routing for the Homematic IP discovery protocol that I didn't find after two days of browsing the internet, or is there a possibility to manually configure the connection between a CCU3 and a DRAP to allow for network segregation?

Well, AFAIK there is no option or way to change how the discovery and communication protocol works between a CCU and a HmIPW-DRAP or HmIP-HAP. In fact, for the HomeAssistant Addon version of RaspberryMatic as well as for a dockerized RaspberryMatic we do have the same issue ATM, namely that communication with a HmIPW-DRAP or HmIP-HAP is not possible if RaspberryMatic is running in a sealed docker environment, simply because docker itself is currently not routing multicast UDP traffic to each individual docker container.

See here: #1373

However, in case of HomeAssistant there is still some work undergoing in the respective internal multicast addon of HomeAssistant which tries to integrate pimd (https://github.com/troglobit/pimd) as a multicast router daemon running on the host network where the docker daemon runs and then should forward all multicast traffic to each individual container (including RaspberryMatic).

See here: home-assistant/plugin-multicast#61

However, I do not know if this might be also applicable to your specific issue (running RaspberryMatic in a secured DMZ), but perhaps you can find out yourself and perhaps also try to help us out with getting the pimd integration in plugin-multicast up&running in case you have enough knowhow regarding multicast routing, etc.

[jkunczik]

Thanks for the detailed answer and rasperrymatic in general! Since I am also running Home Assistant on an RPi4 and control HmIP wired installation over an RPI-RF-MOD, I am aware of your HA add-on. I would love to move the RPI-RF-MOD from a dedicated Pi to the one running Home Assistant, but I was unable to do so because of #1373 and the multicast routing problem.

However, I was able to route other Home Assistant-related multicast traffic (mDNS and SSDP) into my DMZ using avahi and smcroute. I tried to use smcroute to do the same with the homematic multicast traffic but without success. From the above-mentioned issue (troglobit/smcroute#150), I had to learn that 224.0.0.x is not routable, at least with smcroute. I read about pimd, but didn't try it yet, because I thought that dynamic multicast routing would be overkill and wouldn't make a difference in terms of routing multicast addresses, which are specially designated for link-local communication.

Nevertheless, I will dig deeper into pimd to find out, if I missed something. If I find something, I will let you know and also post my findings into home-assistant/plugin-multicast#61.

[jkunczik]

I've just screened the pimd issues for "224.0.0." and found troglobit/pimd#120. This unfortunately confirms that not only smcroute but also pimd can not route link local multicast traffic, because it is blocked by the kernel. Unless one patches the kernel, the decision to use a link-local address for discovery is a show-stopper for my scenario, and for #1373.

[jens-maus]

Thanks that you have checked using pimd for multicast routing. What I am still missing is a small wireshark or tcpdump output of your tests here to actually try to reproduce the issue. Especially interesting would be if you could try to mange the TTL of these 224.0.0.x multicast packages to something higher than 1 since multicast packages are usually set to TTL 1, thus non-routable. The possibility to mange the pages using iptables is mentioned in the issue tickets you were refering and is also mentioned here:

https://troglobit.com/howtos/multicast/
https://tewarid.github.io/2014/11/26/enable-ip-multicast-routing-in-linux-kernel.html

In addition, you could also potentially try to use https://github.com/troglobit/mrouted instead of pimd or smcroute. Furthermore if all of these routing solutions fail there could be potentially a solution by using https://github.com/mcproxy/mcproxy as a multicast proxy between the two networks.

Would be really great to see all this being more deeply analyzed and tested again since I think there really have to be a solution either by manglinge the TTL, using mrouted or mcproxy actually.