search

pitschr / knx-core

KNX Core - A Java library for KNX Net/IP communication
GNU General Public License v3.0
28 stars 12 forks source link

Can it work in an bridged Docker container? #15

Closed StefanOltmann closed 3 years ago

StefanOltmann commented 3 years ago

Hi Christoph.

To make my Smart Home Server project more accesible I now pack it as a Docker image. Instructions for that are at the end of the projects readme file.

I figured out that the network mode must be set to "host" because the (default) "bridged" mode (with explicit exposed ports) does not to work - the response is never received. I wonder why. I set the client channel port to 50011, the data channel port to 50012 and tried TCP and UDP.

Can you tell me which ports need to exposed to make it work? Or is it just not possible to use knx-core in an Docker container with briged networking? Why not?

Kind regards,

Stefan

pitschr commented 3 years ago

Well, with docker and bridge - you now hit a technical limitation of Docker container wich is the broadcast UDP. Assuming you have no firewall settings configured.

knx-core offers according to KNX spec following:

Here we are using the discovery service, which is using the broadcast UDP, the KNX client sends a search request, and your KNX Net/IP device will reply the search response to the host (not the docker container), and the broadcast UDP will not be routed to your docker container.

Solution: you need to use the net host or use a network driver that supports broadcast UDP officially. Or try to google how to handle broadcast UDP with docker, one solution might be: https://github.com/docker/for-linux/issues/637 

net.ipv4.icmp_echo_ignore_broadcasts=0
net.ipv4.conf.all.bc_forwarding=1
net.ipv4.conf.${interface}.bc_forwarding=1

Source: https://www.devwithimagination.com/2020/06/15/homebridge-docker-and-wake-on-lan/

I have not spend much time in that topic yet.

Same issue as above

Without NAT the "Control" and "Data" channels are separated according to the KNX Specification. E.g. Control will have port 50011, and Data will have port 50012.

As you started the communication with Control, this port will be opened by your docker container and therefore also accepting requests for port 50011. But there are no expected communication on 50012 which is not routed by docker.

Solution: I have not tried out it, but I could imagine that configuration of iptables by routing the port of 50011 and 50012 will solve the issue.

With NAT, the "Control" and "Data" channel will be sharing the same port, in this case e.g. 50011. This should not be a problem then using the bridged networking.

My example https://github.com/pitschr/knx-demo-tty-monitor is based on net=host which means all 5 communcation I listed above should be supported. I hope I could give some clarity, but I have not invested much time in bridged networking and therefore I do not have a ready-to-use solution. But AFAIK it is not a limitation of the KNX and KNX client.

If you find a good solution/workaround, then I'm happy to document it as well.

StefanOltmann commented 3 years ago

Okay, thank you a lot. I understand that it's the broadcast UDP that does not get routed and to (maybe) do that there will be a lot of investigation with trial and error to make that work. In that case net=host is fine. I just wanted to make sure that I did not miss something obvious to let in run in bridge mode. ;)

Issue solved. 👍