Kernels react differently to adding mcast membership to the "0.0.0.0" address depending on how interfaces are set up and how the kernel is configured.
In some situations, on Linux, the socket won't even receive Any traffic.
There's no perfect way to solve this, but it makes more sense to add the multicast membership to the same interface address being used by the underlying socket. The other option is to allow the user to supply all the interface IPs to listen on or force them to use setsockopts through a function.
Using if_addr was the smallest change I could think of to fix the weird behaviour.
If people do not supply if_addr or use "0.0.0.0", this essentially reverts back to the previous behaviour.
Checklist
[ N/A ] New functions have typespecs, changed functions were updated
[ N/A ] Same for documentation, including moduledocs
[ N/A ] Tests were added or updated to cover changes
[ ✓ ] Commits were squashed into a single coherent commit
[ ✓ ] Notes added to CHANGELOG file which describe changes at a high-level
Summary of changes
Kernels react differently to adding mcast membership to the "0.0.0.0" address depending on how interfaces are set up and how the kernel is configured. In some situations, on Linux, the socket won't even receive Any traffic. There's no perfect way to solve this, but it makes more sense to add the multicast membership to the same interface address being used by the underlying socket. The other option is to allow the user to supply all the interface IPs to listen on or force them to use setsockopts through a function.
Using if_addr was the smallest change I could think of to fix the weird behaviour. If people do not supply if_addr or use "0.0.0.0", this essentially reverts back to the previous behaviour.
Checklist