As wifi-connect interacts with the device in a multitude of complicated ways, it has been difficult for me to deduce whether the host mode is actually required for its operation.
My scenario is I have something else running in the wifi-connect container, and I want to be able to access that from another container. At the moment, wifi-connect is mounted to host, and my other container to a bridge network, which means they can’t see each other. Rather than make my other container mount to host, it seems it would be better to have the wifi-connect container join the bridge network, if it is possible.
The host mode is for when you don’t want the container to have a separate ip, etc. as compared to the host OS. Given that with wifi-connect we want to configure the device/host OS - and not just a single container - I think we need to stick to the host mode.
I am fairly certain that we’ll have to rewrite wifi-connect to a certain extent if we try to make this work using bridge network mode. Have pinged the wifi connect developer, will update this thread if I have missed something.
Having said that, do you absolutely need to have the something else part in the wifi-connect container itself? You could create a separate container for it. Perhaps there is a different way to do what you want without having to tweak the wifi connect container.
WiFi Connect indeed needs host network mode as it operates on top of the physical WiFi interfaces. There is no way to run it outside of the host network.
You can still communicate with other containers running in bridge network mode though.
Let’s say you have an application called app running next to wifi-connect. You would like it to be able to communicate with the other containers, but those are running in bridge network mode.
There are two use-cases:
app may have an open listening port that applications running in other containers want to connect to
app may need to initiate connection towards applications running in other containers that have listening ports open
For scenario 1.: Since app is running in the host’s network namespace it needs to listen either on the 172.17.0.1 address (the br-xxxxxxxxxxxx interface) or on all addresses (0.0.0.0). Then you can reach app from the bridged containers through the 172.17.0.1 address, which happens to be their gateway.
For scenario 2.: The solution is to define ports in the docker-compose.yml file for the applications running in the bridge network containers and expose those ports to the host’s network namespace. This way app will be able to connect to those ports, since they are available both in the bridged namespace and the host’s namespace.
In both cases you may again consider using iptables to filter out access through eth0 or wlan0 to ports that you don’t want to be available from the external network/Internet. You may apply those from the container running in host network mode.
This is most helpful, thanks. 172.17.0.1 was the answer to my question, I was able to reach the wifi-connect container from another container on its own bridge network by using 172.17.0.1.