2 user space programs over tun using multicast - c

Question

I am still getting my hands-on with networking programming for linux and please feel free to clear my understanding if you feel its vague or incorrect.
Query:
I have baked a Linux image using yocto project which is similar to core-image-minimal. This part is irrelevant for the query. I boot this image using QEMU emulator and when QEMU is booted up it creates a sudo interface by the name tap0. The IP of the QEMU is 192.168.7.2 and tap0 i guess has IP 192.168.7.1.
Now I have another user space program written in simple C which tries to listen whatever the QEMU program(node) is sending. So, I use a fragment similar to this:
if ( (fd = open("/dev/net/tun",O_RDWR)) < 0) PERROR("open");
memset(&ifr, 0, sizeof(ifr));
ifr.ifr_flags = TUNMODE;
strncpy(ifr.ifr_name, "w-tap%d", IFNAMSIZ);
if (ioctl(fd, TUNSETIFF, (void *)&ifr) < 0) PERROR("ioctl");
printf("Allocated interface %s. Configure and use it\n", ifr.ifr_name);
s = socket(PF_INET, SOCK_DGRAM, 0);
sin.sin_family = AF_INET;
sin.sin_addr.s_addr = htonl(INADDR_ANY);
sin.sin_port = htons(PORT);
if ( bind(s,(struct sockaddr *)&sin, sizeof(sin)) < 0) PERROR("bind");
fromlen = sizeof(from);
while(1) {
l = recvfrom(s, buf, sizeof(buf), 0, (struct sockaddr *)&from, &fromlen);
//print the data etc
}
Now If I start this C code with say sudo ./tun_proxy 1534, I am able to listen the messages on this port sent by 192.168.7.2.
Further,
I Boot up QEMU with additional option -net socket,mcast=224.244.224.245:30490 since baked image has a small program in it to send some messages as broadcast on the multicast group and port. Also, I should be able to listen these message on the previous tun_proxy application. I even created a new thread in that which tries to listen on the multicast group but I get the error message as "already in use"
Where exactly is my understanding wrong? All I need is 2 user space programs, one of which is a QEMU to communication via multicast messages.

Answer 1

Your understanding is sound, there are just 2 problems you need to address:
If you bind on INADDR_ANY you are blocking the port for all other addresses (including multicast) unless you use REUSEADDR. Your INADDR_ANY bound socket would also be receiving the multicast it is blocking access to, except:
Some socket on a "host" needs to use IP_ADD_MEMBERSHIP where the membership request matches the traffic before any sockets will receive the multicast traffic.
Emulating your current example:
As an equivalent but rather bizarre example, shell1 is equivalent to your listener and shell2 shows that a seemingly unrelated socket's ip-add-membership (but for the correct address and all interfaces) causes it to receive traffic:
shell1$ socat UDP-RECVFROM:30490,bind=0.0.0.0 EXEC:date
shell2$ echo hi | socat UDP-DATAGRAM:224.244.224.245:30490 STDIO
shell1$ (socat is still waiting for a packet)
shell2-add-membership$ socat UDP-RECVFROM:1044,reuseaddr,bind=127.0.0.1,ip-add-membership=224.244.224.245:0.0.0.0 EXEC:date&
[1] 16003
shell2$ echo hi | socat UDP-DATAGRAM:224.244.224.245:30490 STDIO
Thu Sep 1 00:16:28 CEST 2016
shell1$ (socat now exits cleanly)
Fixing it for multicast:
So to run 2+ clients, the correct method would be:
shellclient1$ socat UDP-RECVFROM:30490,bind=0.0.0.0,reuseaddr,ip-add-membership=224.244.224.245:0.0.0.0 EXEC:date
shellclient2$ socat UDP-RECVFROM:30490,bind=0.0.0.0,reuseaddr EXEC:date
...
shellclientn$ socat UDP-RECVFROM:30490,bind=0.0.0.0,reuseaddr EXEC:date
shell2$ echo hi | socat UDP-DATAGRAM:224.244.224.245:30490 STDIO
Thu Sep 1 00:16:28 CEST 2016
...
Notice that all must use SO_REUSEADDR, but only one must add membership.
Qemu's socket network uses SO_REUSEADDR and does an membership. So the code blocking the socket is probably other code that needs to be modified to be like Qemu.