0

My understanding is this, if a socket does not bind local address(or binds to INADDR_ANY), and does not call connect() to set remote address/port, then there is no way to prevent unicast packets to be delivered to a multicast listening socket, or vice versa, since the only check remaining when a packet reaches the UDP layer is port number match (again, since the other criteria such as remote/local addresses are both zero). The hypothetical scenario I can think of is like this:

  1. on a machine with one interface, primary IP address is IP_ADDR
  2. socket A listens to UDP multicast address MULTICAST_IP_A with port number PORT_A
  3. socket B listens to UDP unicast, on PORT_B

Then are any of the following statements true?

  1. multicast packet sent to group address MULTICAST_IP_A with port number PORT_B will be delivered to socket B
  2. unicast packet sent to IP_ADDR:PORT_A will be delivered to socket A

I looked into the Linux IPv4 source code and so far it seems that the above two will happen, for example, __udp_is_mcast_sock() would return true even if inet->mc_list is empty, because inet_create() sets inet->mc_all to 1. But I'm no expert, would like to hear someone validate/invalidate the claims and maybe give some pointers to the code. thanks!

Improve this question

1 Answer 1

Reset to default
1

Note that udp_is_mcast_sock() will return false if the local address is not multicast (see ip_mc_sf_allow).

For both questions, this post might help: What does it mean to bind a multicast (UDP) socket?

For case 1.

  • multicast packet sent to group address MULTICAST_IP_A with port number PORT_B WILL NOT be delivered to socket B

For case 2.

  • unicast packet sent to IP_ADDR:PORT_A WILL be delivered to socket A. UDP multicast socket will bind on 0.0.0.0, that's why. You can launch a server and run netstat -aun to see that, although you might already have one on port 5353 (avahi/mdns).

You can check this and other situations with the python multicast client/server programs in this post. To simulate the unicast client/server behaviour you can use nc (netcat).

Improve this answer
4
  • Thanks for the answer. ip_mc_sf_allow() is exactly what I found counter intuitive. For case 1, a multicast packet arrives, in ip_mc_sf_allow(), loc_addr is indeed the multicast group IP address, so ipv4_is_multicast(loc_addr)==true. And what happens is that inet->mc_list is empty for socket B, so ip_mc_sf_allow() returns the value of inet->mc_all, which was set to true in inet_create(). Did I miss something here? Commented May 18, 2020 at 15:36
  • I'm not that familiar with the structures, just tried to answer your question. But if you are digging that deep, you might consider compiling the kernel and add some debugging to that routine. It's fun and you cannot get much closer than that to the code and actual inner workings. Commented May 18, 2020 at 15:42
  • Understood. I was referring to "Note that udp_is_mcast_sock() will return false if the local address is not multicast (see ip_mc_sf_allow)", which is intuitive and consistent with your conclusion on case 1, but the code seems to suggest otherwise. Will dig deeper. Commented May 18, 2020 at 15:54
  • Ok. And you're welcome ;) By the way, do follow the return values. You might be expecting 0 to be false and 1 true but that's not what I read in that particular function. Commented May 18, 2020 at 18:59

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.