I'm solving a problem with hosting Home Assistant instance in a cloud. As multicast is not supported on the way there, I convert multicast packets to unicast on my home router (by using DST-NAT) and send them to Home Assistant server via PPP link.
The problem is that on server side, simply converting destination address back to multicast one (224.0.0.50) is not working for Home Assistant to actually receive the packet, so the only solution I found is binding the socket not to the multicast address (224.0.0.50) but to 0.0.0.0 using sock.bind(('', port)) (which is default for Windows and a fallback for other cases) instead of sock.bind((MULTICAST_ADDRESS, port)).
What are the pros (like "working gateway pushes over non-multicast networks") and cons of binding to 0.0.0.0 instead of 224.0.0.50? I'd like to upstream a solution for this use case, as a friend of mine also faced this problem previously.
Hello.
I'm solving a problem with hosting Home Assistant instance in a cloud. As multicast is not supported on the way there, I convert multicast packets to unicast on my home router (by using DST-NAT) and send them to Home Assistant server via PPP link.
The problem is that on server side, simply converting destination address back to multicast one (224.0.0.50) is not working for Home Assistant to actually receive the packet, so the only solution I found is binding the socket not to the multicast address (224.0.0.50) but to 0.0.0.0 using
sock.bind(('', port))(which is default for Windows and a fallback for other cases) instead ofsock.bind((MULTICAST_ADDRESS, port)).What are the pros (like "working gateway pushes over non-multicast networks") and cons of binding to
0.0.0.0instead of224.0.0.50? I'd like to upstream a solution for this use case, as a friend of mine also faced this problem previously.