Does the behavior described in
http://lists.freebsd.org/pipermail/freebsd-net/2003-October/001726.html apply to
Solaris 8 systems? Also, can you tell me what the difference is between binding
IPADDR_ANY, a local network ip address or multicast ip address to the socket and
should you use the sam
I've filed PR's with a patch for this issue now to most of the affected
operating systems. It's basically anything derived from 4.4BSDLite
that hasn't already corrected for this issue.
FreeBSD: kern/58359
NetBSD: kern/23221
OpenDarwin: bugzilla id 1062
OpenBSD: no reply, I'll refile later this
Sounds good to me :)
At the very least, this would improve the performance of the
mDNSResponder. mDNSResponder has some additional code to get the
interface the packet was received on so it can filter out the packet if
it wasn't received on the interface that socket is bound to/associated
with
On Tuesday, October 21, 2003, at 12:59PM, Joshua Graessley wrote:
On Oct 21, 2003, at 12:28 PM, William A.Carrel wrote:
I have two such sockets set up, one on each of the interfaces I'm
interested in. The problem is that a packet that comes in on one
interface winds up in the receive queue for
This is "by design". When you perform IP_ADD_MEMBERSHIP, it assures you
that the interface you've selected will receive packets destined for
the multicast address you specify. It will deal with any IGMP traffic
necessary for joining the group.
When a packet is received on any interface, the pac
I've been working on a miniature multicast routing program and am
encountering some troubles with getting setsockopt(2) to create the
right behavior.
I pass in
setsockopt(the_sock, IP_ADD_MEMBERSHIP, &the_mreq);
with the_mreq having in_addr's for the link-local multicast channel I'm
interested
