@neild

Hi,

I've had a deeper look into the socket setup from the golang executable using strace. When the socket is being setup it is not bound to the actual group address. Instead it is being bound to 0.0.0.0 . This causes all packets received on a interface destined to the provided port to be delivered to the program userspace. This doesn't only create some unexpected data to be received in user program, but also performance impact as unneeded data is being copied from kernel space to userspace (though I'm no expert here).

I guess a modification is required in net/sock_posix.go netFD.dial to correctly bind to the group address. Though I might have made a wrong turn following the function calls.

The fourth line in the strace output is the line of interest.
The Call in the second line of the strace also seems unexpected for me as multicast doesn't have anything to do with broadcast.

main() {
con, err := net.ListenMulticastUDP("udp", nil, &net.UDPAddr{
Port: 3000,
IP: net.IPv4(239, 0, 20, 21),
})
if err != nil {
slog.Error(err.Error())
os.Exit(1)
}
con.Close()
}

strace output from where the socket setup starts

socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 3
setsockopt(3, SOL_SOCKET, SO_BROADCAST, [1], 4) = 0
setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
bind(3, {sa_family=AF_INET, sin_port=htons(3000), sin_addr=inet_addr("0.0.0.0")}, 16) = 0
epoll_create1(EPOLL_CLOEXEC) = 4
eventfd2(0, EFD_CLOEXEC|EFD_NONBLOCK) = 5
epoll_ctl(4, EPOLL_CTL_ADD, 5, {events=EPOLLIN, data=0x62d938}) = 0
epoll_ctl(4, EPOLL_CTL_ADD, 3, {events=EPOLLIN|EPOLLOUT|EPOLLRDHUP|EPOLLET, data=0x7f620dc73eb00001}) = 0
getsockname(3, {sa_family=AF_INET, sin_port=htons(3000), sin_addr=inet_addr("0.0.0.0")}, [112 => 16]) = 0
setsockopt(3, SOL_IP, IP_MULTICAST_LOOP, [0], 4) = 0
setsockopt(3, SOL_IP, IP_ADD_MEMBERSHIP, {imr_multiaddr=inet_addr("239.0.20.21"), imr_interface=inet_addr("0.0.0.0")}, 8) = 0
epoll_ctl(4, EPOLL_CTL_DEL, 3, 0xc000069dcc) = 0
close(3) = 0
exit_group(0) = ?
+++ exited with 0 +++

As per the code, it intentionally binds to 0.0.0.0 instead of the original address.

I wonder if such a policy decision should be made so deep/close to the kernel. I would think it would be rather simple to enforce such a policy in some higher level function where one could actually make a conscious decision if they want a wildcard socket or not.
Imagine a system running a 100 processes where each process is responsible for recording a video multicast stream. This wildcard socket policy would easily cripple a system as each process would get the data for each of the subscribed multicast streams.

I'm definitely not the expert here, and I don't understand the comment in the code. It was introduced in 0ae8078.

It seems to me the that the standard library should not be binding to 0.0.0.0 like this. Clearly net.ListenMulticastUDP is going to join exactly one group address. So what use case exactly is referred to by the comment? Anyone that wants to join two groups must already be doing that themselves somehow. They ought to be explicit and bind to 0.0.0.0 in the first place.

This would also fix the current surprising behavior where c.LocalAddr() gives 0.0.0.0 instead of the multicast address.

I've looked at the commit message, From that message I assume that fuctionallity was pushed down the stack which should have been solved at a higher level. namely the ipv4 package in this case.
I'm not sure yet on how this can be rectified without impacting backwards compatibility.

@mrinny do you have an example of how an application could be relying on the current behavior?

I off course don't have knowledge about all usecases. Though I think maybe in a discovery system where one could receive announces from multiples groups and consolidate them in a single socket. I've been using multicast just as multimedia transport. which has other contraints that using it as a messaging transport I would imagine.
I'm going to reach out to @cixtor. Maybe he can shed some light on this.

just some small feedback.
I've commented out the switch in the standard lib of my go1.24.2 install. Recompiling my binaries result in the behavior I would have expected.