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  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 11 Jul 2008 12:00:57 -0700
From:	David Stevens <>
To:	Neil Horman <>
	Alexey Kuznetsov <>,,,
Subject: Re: [PATCH] IPv4 Multicast: prevent reception of mcast frames from	unjoined

Yes, that's me, and that's also true. It wasn't the address, it's the time 
delay. I think that
was months ago. But you left out a distinguishing piece in your example 
here, which is
all the difference.

Joins are also per-interface. So, joining a group on "lo" does not join 
the group on
"eth0". In your example below (4), the reason it won't receive the packets 
is because
the machine is not a group member on eth0. If any process joined the group 
on eth0
then an INADDR_ANY-bound socket would receive them (whether it joined or 
I guess I wasn't clear -- the reason you have to join below is to 
guarantee someone
has joined. If some other process already joined on that interface, you 
receive them also.


Neil Horman <> wrote on 07/11/2008 11:23:04 AM:

> >>>
> >>> 4) Finally, what if process B bound itself to INADDR_ANY rather than 
> >>>the
> >>> specific multicast group.  Should it see process A's sent frames 
> >>
> >>        Not if the group membership is on lo and the sends are on 
> >>The
> >>reason it isn't seeing the packets is not the binding, but the group
> >>membership. To hear packets you're sending out an interface, you must
> >>join that group on that interface *and* the sender must allow loopback 
> >>not clearing IP_MULTICAST_LOOP. Joining the group on a different 
> >>really is joining a different group, as far as multicasting is 
> >         But in the sentence above, I think you missed the point of the
> > mail I sent before. Joining a group or not on a particular socket has
> > nothing at all to do with delivery of multicasts to the socket.
> > 
> >         Multicast addresses, like unicast addresses, are for the 
> > machine, not just the socket that does the join. If anyone on the
> > machine has joined the group and your binding matches the packet, you
> > will receive a copy. That's intentional. If you don't join any groups
> > at all, but bind to INADDR_ANY, you will receive packets for the port
> > and protocol and any local unicast or multicast address (including
> > groups joined by any other process on the machine).
> > 
> >  +-DLS
> If thats the final word, then I'll believe you, but it seems to me that
> receiving multicast traffic on a socket that didn't specifically join a
> multicast group is asking for trouble, as every application needs to be 
> to handle data payloads it was not expected to recieve.
> Can you clarify your statement above with the one that I copied in from 
> earlier?
> Regards
> Neil
> -- 
> /****************************************************
>  * Neil Horman <>
>  * Software Engineer, Red Hat
>  ****************************************************/

To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists