Re: [IGMPv3/MLDv2] Problem using host implementation on 2.6.0-test1

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> Actually, I tried the KAME code for FreeBSD4.7/4.8, and it is rather
> unstable, particularly in IPv6 (kernel errors which freezed the
> system). The second one i try was the patch for the NetBSD 1.6
> kernel, which worked well. If you are interested, i've made a little
> documentation on the tests done under NetBSD.

Ok, maybe it's better to send your problem report to kame-snap
mailing-list.

> i only noticed one thing that i think can be annoying : When a
> filter is set to INCLUDE{A} (where A is a source list) or EXCLUDE{A}
> and we remove the last source from the filter with a
> MCAST_UNBLOCK_SOURCE or a MCAST_LEAVE_SOURCE_GROUP operation, then,
> when we intended to be in EXCLUDE{} or INCLUDE{} , no filter is set
> anymore as if we had left the group. It can be problematic, i think,
> because instead of being in EXCLUDE{}, where we receive the data
> from all the sources, none is received.

# Sorry for talking deeply about SSM in this mailing list...

I cannot understand the sentence from "when we intended to be in ..."
You had better show more detail procedures, including each option name
of setsockopt() (or advanced APIs).

Ok, anyway let's show some examples here.
For example, do you mean the following situations?
	1. Join INCLUDE{a}, Join INCLUDE{b}, Join INCLUDE{c}
	   (using MCAST_JOIN_SOURCE_GROUP)
	2. Leave INCLUDE{c}
	   (using MCAST_LEAVE_SOURCE_GROUP)
	3. Join EXCLUDE{}
	   (using MCAST_JOIN_GROUP)
	4. Kernel returns error

If above example is the one what you did, then I can understand your
situation. The answer is, if you specify Basic APIs in procedure.3,
then kernel returns error. This is correct behavior, which is defined
in the MSF I-D. The reason is Basic API doesn't support to change
filter mode from IN to EX or vice versa. In order to make it work,
you must use Advanced APIs. Or you must leave each a and b by
MCAST_LEAVE_SOURCE_GROUP 

> > But anyway, why e.g. struct ip_mreq_source defines each data to __u32
> > type, not struct in_addr? The MSF I-D explicitly mentions they are
> > struct in_addr.

This question is still opened.
--
Hitoshi Asaeda
-
: send the line "unsubscribe linux-net" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Netdev]     [Ethernet Bridging]     [Linux 802.1Q VLAN]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Git]     [Bugtraq]     [Yosemite News and Information]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux PCI]     [Linux Admin]     [Samba]

  Powered by Linux