Context:
I have Hassio 9.3 64 bits on a Raspberry Pi 4
Problem
I have an ip conflict, my eth0 is 172.17.0.0/16 and docker0 is 172.17.0.1/16, so when Hassio turns on Docker it stops pinging my local network.
Failed solutions:
I can’t change /etc/docker/daemon.json (change the IP range that Docker works with) because it is read-only.
Modifying the IP manually every reboot time seems crazy to me.
What I can do?
More info:
Help! <3 there is no solution?
I try to mount a micro-SD in other computer but it make read-only :,(
Hello, any help? I have Home Assistant half installed because I can’t fix this. Don’t you think Hassio is too strict?
I did take a look at this some, and sorry to say I could not come up with a solution.
Be aware that 172.17.0.0/16 is not a valid host IP address since the 172.17.0.0 and 172.17.255.255 are considered as reserved addresses.
Maybe set your HA IP to 172.17.255.254 or something pretty high within the subnet.
For sure the best thing to do would be to change your LAN subnet to another subnet address, but I’m sure you have already considered that.
Tommy thanks your reply!
My host has an ip in the range 172.17.0.0/16 exactly 172.17.2.91.
You can see that the docker documentation talks about this conflict and the possible solution
How to change the default docker subnet IP range.
But the host has read-only file system and I can’t change it
I need alternative. I’m lost.
Why don’t you change the range of your network?
I have everything under DHCP ( with reservations for devices i want to use a fixed address), so it’ll be easy to change…
I may have to retract this earlier statement. I took a look at the iptables, and anything leaving docker0 bridge with source address 172.17.0.0/16 will be NAT’d. I haven’t mapped out how/when containers use docker0, but it could be a problem if HA ethernet port tries to use any of the 172.17.0.0/16 addresses.
Yeah I don’t know what to tell you in this case.
Remount the read only Partition as rw… or did you try it already?
I have many devices. Home assitant must adapt to our needs, it is absurd that it does not allow to modify things that are known problems.
I have not been able to do it, I tried it with another computer, how do I do it?
Every feature requires time to implement it. It may be a known issue but its not particularly common. Rarely comes up in issues and the feature request only has one vote.
If it’s important to you feel free to submit a PR. Or vote on the fr if you can’t or don’t want to do that.
In the meantime there’s two workarounds:
When using 172.17.0.0/16 on eth0, no container has access to the network, it is curious that it does reach the internet.
no devices on the network have access to the containers.
I’m software developer and maybe i would like to help.
But I wouldn’t know where to start.
Would you change the HAOS installation configuration? like wifi?
I don’t think it makes sense to put a configuration in the HomeAssitant.
What do you think?
So I haven’t planned this particular feature out yet but here’s a rough outline. This wouldn’t be an HAOS configuration file thing, there really aren’t any of there. When changing things on the host (like network config, moving the data disk, etc.) the way it is done is via supervisor.
First there would need to be some service running on the host which supervisor can talk to and tell it the subnet to change docker to. Supervisor can talk to docker but since changing this requires modifying the daemon.json file there would have to be another service running on the host which does that. Supervisor talks to such services over D-Bus. We can either ship a simple one capable of this with operating system or add this capability to os-agent if it can work for supervised systems as well.
Then supervisor would need a new api which accepts a new subnet to use for docker. It then passes that to the service as discussed. This can then either restart docker immediately or create a repair telling the user they need to reboot the host to apply the change.
Finally with all new APIs added to supervisor there would need to be a PR to the CLI to add a way to use the new API and to developers.home-assistant.io to document the new API.
Last but not least, you’d need to change this:
Supervisor currently has the subnets it uses for its components and addons hard-coded as constants. There would need to be a way for supervisor to determine the subnet in use and carve out two spaces from that subnet - one for its fixed number of internal components (currently 172.30.32.0/23) and one for the dynamic number of addons (currently 172.30.33.0/24). Ideally the service that supports changing docker’s subnet also provides the current value of the docker subnet as a dbus property.
Operating system does have some support for configuration like this. Where the user inserts a USB formatted a particular way with a particular name and the user calls ha os import and then OS looks for particular files on it. You would still need a service running on OS which looks for the file with this new subnet and knows what to do with it though. You can’t ask the user for an entire daemon.json file as many of the customizations to this file would break HA and/or Supervisor. It would have to ask for a new subnet specifically.
I wouldn’t really recommend this approach. Supervisor still needs to know what the subnet is which means you still need to make a new service that supervisor can talk to over dbus to learn what the docker subnet currently is (unless you can find a way to determine that from one of docker’s APIs). Which means you basically still end up doing most of the work I laid out above (changing the hard-coded values, making a new host service, getting supervisor talking to it over D-Bus, etc.). But then instead of having an easy CLI option to change the subnet, users have to deal with figuring out how to get a USB configured the right way and physically plug it in.
In general the USB only config options are considered legacy currently. They still exist but we don’t really want to add new ones because they are difficult to use. The preferred approach is to add options to the CLI and/or UI and have supervisor then talk to a service on the host like I explained above.
Ugh it’s very complicated and involves various parts of the system.
I’m looking at code and there are parts that I see very few examples like the Os-Agent
Yes that’s true. For something like this if it was easy I definitely would’ve knocked it off by now. I do a lot of development on supervisor (as you might’ve gathered from my detailed explanation above). While the selected range doesn’t seem to create conflicts for most users it obviously would be better if it could be changed. I imagine it will happen at some point but it might be a while.
Until then these are the solutions available now:
Assuming #1 is quite a hassle from your comments above then switching the installation type is probably the best current option.
I come from a supervised installation and I have experienced 2 very hard updates, that I want HASSOS.
I start a Supervise and this is a network in debian:
5: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
link/ether 02:42:f1:ad:8b:87 brd ff:ff:ff:ff:ff:ff
inet 172.18.0.1/16 brd 172.18.255.255 scope global docker0
valid_lft forever preferred_lft forever
inet6 fe80::42:f1ff:fead:8b87/64 scope link
valid_lft forever preferred_lft forever
Docker by default maybe has a range newtork control