Check the example in the Home Assistant zeroconf integration on how to specify

https://github.com/home-assistant/core/blob/81cac25bd01c26b8076c938a40a3677d9baf58b0/homeassistant/components/zeroconf/__init__.py#L196

https://github.com/home-assistant/core/blob/81cac25bd01c26b8076c938a40a3677d9baf58b0/homeassistant/components/zeroconf/__init__.py#L196

@bdraco this specifies the interfaces the zeroconf tries to bind to. For the use case that I have I need to add two interfaces to the multicast group while only binding to one of the two.

While I'm still not 100% sure what you are asking for, InterfacesType does allow specifying a list of ip addresses:

The code to normalize the choices is at

If you need something more complex we could accept a PR to expand the options.

Apologies about the lack of information, I opened this issue while being on mobile. I will provide more details tomorrow when I have more time :)

I think the best way to articulate the issue is as follows:

On iOS, multicast messages sent to and from the device may not be received unless the device explicitly joins a multicast group on both its local IP and 127.0.0.1. Currently(assume interfaces=[localhost, local_ip]), Zeroconf attempts to bind to port 5353 on both those interfaces which will fail because of iOS sandboxing.

Ideally zeroconf's implementation should support the following:

• binding to a specific interface
• creating a multicast group for the bound socket consisting of explicitly defined addresses/interfaces

I will likely create the PR for this tomorrow assuming I have time. Are there any contribution guidelines for this project?

Thanks for the additional details. That makes a lot more sense now. It would be helpful if you could also post the log of the exceptions/errors that happen for additional context.

I will likely create the PR for this tomorrow assuming I have time. Are there any contribution guidelines for this project?

Commit messages should follow https://www.conventionalcommits.org/en/v1.0.0/ to keep the CI happy, however as long as the title of the PR does it will get squashed in the end anyways.

Also keep in mind we eventually need to implement run time reloads to solve home-assistant/core#59553 so any changes should think about that a bit

Also keep in mind we eventually need to implement run time reloads to solve home-assistant/core#59553 so any changes should think about that a bit

Is zeroconf technically a home-assistant project or are they just tightly intertwined? Just so I know what to look out for

Thanks for the additional details. That makes a lot more sense now. It would be helpful if you could also post the log of the exceptions/errors that happen for additional context.

I will likely create the PR for this tomorrow assuming I have time. Are there any contribution guidelines for this project?

Commit messages should follow https://www.conventionalcommits.org/en/v1.0.0/ to keep the CI happy, however as long as the title of the PR does it will get squashed in the end anyways.

I will provide some logs later today, it isn't obvious to be honest that something is wrong. When you bind to all addresses it configures a correct multicast group but wont actually broadcast because of using two unique interfaces(seems to be a posix issue but honestly not sure. I think the kernel doesn't know which interface to use for multicast and decides on neither) while actively using those two interfaces. When you bind to just localhost you wont have any issues other than not receiving anything!

Also keep in mind we eventually need to implement run time reloads to solve home-assistant/core#59553 so any changes should think about that a bit

Is zeroconf technically a home-assistant project or are they just tightly intertwined? Just so I know what to look out for

zeroconf is not a Home Assistant project. It is the largest known user base for this project though and the source of most issue reports. ie. this project's largest customer.