netdev - RE: Multicast IP packet routed between 2 ports nic on the same host

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Tue, 7 Jun 2011 10:03:55 -0700
From:	David Stevens <dlstevens@...ibm.com>
To:	BONNEAU Guy <gbonneau@...anda.com>
Cc:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"netdev-owner@...r.kernel.org" <netdev-owner@...r.kernel.org>
Subject: RE: Multicast IP packet routed between 2 ports nic on the same host

netdev-owner@...r.kernel.org wrote on 06/07/2011 06:57:32 AM:

> From: BONNEAU Guy <gbonneau@...anda.com>
 
> Its works! Thanks a lot David! Googling for SO_BINDTODEVICE helped 
> me to get insight into my issue. This link was really useful : 
> http://codingrelic.geekhold.com/2009/10/code-snippet-sobindtodevice.html
> . However I'm still somewhat confused because I always assumed that 
> this was one of the purpose of IP_ADD_MEMBERSHIP beside joining a 
> multicast group. To constrain the multicast socket to a specific 
> "device" interface. In which case I wonder if the interface member 
> of structure ip_mreq is still relevant? Can you comment!

Guy,
        There are 2 steps in multicast delivery:

1) group membership, which is controlled by IP_ADD_MEMBERSHIP (et alia).
        This is per-interface and determines whether multicast packets
        on that interface will be delivered to the machine. If you don't
        join a group _on_that_interface_, the interface itself will drop
        the packets. This is what the interface specification in ip_mreq
        and ip_mreqn is for; if you want that group on all interfaces,
        you have to do the join on all interfaces, one at a time. If you
        don't specify an interface, it'll pick one, which isn't 
necessarily
        the one you want.
2) socket binding.
        This determines whether a particular socket receives a multicast
        packet or not. Clearly, all multicast packets that are not 
delivered
        to the machine will not be delivered to any socket, so _somebody_ 
has
        to have done a group join for sockets bound to multicast addresses
        to receive packets. However, the socket binding is entirely 
independent
        of the group membership. A binding matching the group and port 
(which
        also includes INADDR_ANY bindings) will receive matching packets
        whether or not you did a join on that socket (or a join at all) as
        long as some process on the machine has done a join on an 
interface
        that allows delivery to the machine.

In your test program, you were using the same group and port for both
instances so they will both receive the same set of packets. If any join
on any interface would allow delivery of matching packets to the machine,
they would both receive them, even if neither of your programs did the
IP_ADD_MEMBERSHIP. And if no process had done an join on an interface
with matching multicast traffic, neither of the programs would receive
anything.

                                                                +-DLS

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html