I think the field name is kind of confusing here. It appears
that local_df == 1 means allow fragmentation and
local_df == 0 means don't fragment. But DF to me
means don't fragment, as in IP_DF, so the field value
is backwards from what I'd expect. And maybe that's
what happened to in your patch,
Pekka,
I first thought the interface might be down when I saw this
one, except the interface route is present in the route list he shows
later. That's normally deleted when the interface is down.
And a failure to be in the group just wouldn't answer--
shouldn't cause net
Another relevant piece of information is what the socket is
bound to; netstat -au will tell you if you're bound to an address
that will match the incoming multicast packets.
If you suspect that the VLAN device is the problem, then it'd be
a good idea to try it on ordinary ethernet.
Re:
NACK.
Daniel,
This code is part of the in-kernel API for anycast, which is
intended
to be the same as for multicast. By removing support for NULL there,
you're
making a special case for the anycast code that isn't there in the
multicast
code (can't support a NULL dev), and you really
You need to join the multicast group on the interface you want
to receive it. If you're setting both imr_address and imr_index
to 0, you haven't specified an interface.
Instead of setting imr_ifindex to 0, try setting it like this:
imr.imr_ifindex = if_nametoindex(eth0);
(or whatever interface
RFC 2011 doesn't apply to IPv6, and the internal names of /proc entries
are not used by the SNMP protocol, but it is an unintentional
incompatibility with the
previous Linux entry names, so I agree. :-)
+-DLS
Acked-by: David L Stevens [EMAIL PROTECTED]
Herbert Xu [EMAIL PROTECTED] wrote on 01/16/2008 03:49:01 AM:
Actually having the icmp_out_count call in ip_push_pending_frames seems
inconsistent. Having it there means that we count raw socket ICMP
packets
too. But we don't do that for any other protocol, e.g., raw UDP packets
don't get
[EMAIL PROTECTED] wrote on 01/16/2008 03:17:29 PM:
Fair enough. How about moving this code back into icmp.c and just
add a new count call in raw.c? The push pending function is used on
the UDP fast path so the leaner it is the better.
I started out with it there, but it certainly
Brian,
Looks good to me.
+-DLS
Acked-by: David L Stevens [EMAIL PROTECTED]
How about the simple patch below? I just removed the ENINVAL check from
my original patch, but it accomplishes the same thing.
...
Signed-off-by: Brian Haley [EMAIL PROTECTED]
Daniel Lezcano [EMAIL PROTECTED] wrote on 01/03/2008 03:00:48 AM:
...
With this solution, we can handle different values for the namespaces
but these values are driven by the initial network namespace because
their values are lesser or equal to the one from the initial network
namespace.
Daniel,
I'm not sure what benefit you get from making this per-namespace.
The point of it is really to prevent one (non-root, even) application from
killing machine performance with source filters (because maintaining them
is an n^2 algorithm). It's a weak constraint, but the resources
Vlad Yasevich [EMAIL PROTECTED] wrote on 12/19/2007 07:20:53 AM:
But this still requires either a SO_BINDTODEVICE or sin6_scope_id. This
means the an application can call BINDTODEVICE(eth0), MULTICAST_IF(eth1)
issue a connect on a UDP socket an succeed? Seems wrong to me.
Can you check
Brian Haley [EMAIL PROTECTED] wrote on 12/19/2007 07:35:46 AM:
...
if (usin-sin6_scope_id)
sk-sk_bound_dev_if = usin-sin6_scope_id;
if (!sk-sk_bound_dev_if
(addr_type IPV6_ADDR_MULTICAST))
We would still have to check np-mcast_oif is set in the link-local case
since we shouldn't be getting here with a zero.
Actually, that's one of the things I wanted to look into. I'm not
sure if there's a path through here with (even non-linklocal) multicasts
that end up without an
Brian Haley [EMAIL PROTECTED] wrote on 12/18/2007 12:57:54 PM:
Trying to connect() to an IPv6 link-local multicast address by
specifying the outgoing multicast interface doesn't work, you have to
bind to a device first with an SO_BINDTODEVICE setsockopt() call.
No, you simply have to
Brian,
OK, I see what you're trying to fix now.
I think the scope_id checks are not quite right-- they
should be something like this:
if (addr_typeIPV6_ADDR_LINKLOCAL) {
if (addr_len = sizeof(struct sockaddr_in6)) {
if (sk-sk_bound_dev_if usin-sin6_scope_id
I don't know if you've fixed it already, but I was writing some
UDPv6 tests in 2.6.23.9 and was getting EDESTADDRREQ unexpectedly. When
I looked at the kernel code, I found:
gerrit/wscott 1.115 | int udpv6_sendmsg(struct kiocb *iocb,
struct sock *sk,
shemminger1.57
Never mind...
Though I hate the TCP in the name (maybe overload UDP_CONNECTED?), I see
datagram
sockets are in fact setting it, and my EDESTADDRREQ was a bug in my test
program. :-)
+-DLS
[EMAIL PROTECTED] wrote on 12/09/2007 04:19:12 PM:
Maybe I'm more used to hex, but I personally don't think those are
more readable. It replaces 1-line macroes with 4-line functions, and
I think more vgrepping to pick out the relevant constant data.
+-DLS
-
To unsubscribe from this list: send the
Pekka,
Thanks! That answers the question I had (i.e., you believe the
legal
issues are resolved).
+-DLS
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Last I heard, there are Intellectual Property claims with ISATAP,
which is why the RFC is not standards track and which makes it
effectively a proprietary protocol.
Unless that's been resolved, I think the claim by the IP owner is
that it can't be distributed without a license from them. So,
I guess license is no longer required for implementers of ISATAP.
Is it right, Fred?
https://datatracker.ietf.org/ipr/550/
Does this also allow license-free redistribution?
I'm certainly no lawyer, but I don't see the point of
having a patent that doesn't restrict *something*. :-)
give it away on this specific instance. I'm not sure if you should
attribute to hidden agendas what you can explain by doing the right
thing (granted, very few companies do this which may make it suspect,
but still..).
Pekka,
I'm not assuming hidden agendas here; I simply don't
[EMAIL PROTECTED] wrote on 10/29/2007 11:03:37 AM:
So, I am looking for technical reasons why this is permitted.
Vlad,
Is there a technical reason to disallow it? Rather than
anticipate all the possible uses for a machine, it's, of course,
generally better to restrict only the things
For v6, there are plenty of operational reasons to not allow this. You
really
turn unicast into anycast when you do this and there are special rules
to
be followed.
I don't see it that way. The only problem I can think of offhand
is that you can't use a multi-interface address to
Dave,
I didn't see a response for this one... in case it fell through
the
cracks. Just want to make sure my bone-headed error doesn't hang
around too long. :-)
+-DLS
- Forwarded by David Stevens/Beaverton/IBM on 10/29/2007 01:51 PM
I don't see any problem with this. If you're using IP_MULTICAST_IF with
a bound socket, it forces you to use that interface, anyway.
I'm not sure multicasting works as expected in some other cases with
bound sockets (looks like there may be some holes to evade the
binding), but that's in old
What about just removing it, or do you think it's
useful for documentation of the order? Either way,
Acked-by: David L Stevens [EMAIL PROTECTED]
+-DLS
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote on 10/25/2007 04:05:13 PM:
David Stevens [EMAIL PROTECTED] wrote:
What about just removing it, or do you think it's
useful for documentation of the order? Either way,
I don't know whether it's intended to be used for something, perhaps a
debugging macro
[EMAIL PROTECTED] wrote on 10/24/2007 09:24:10 AM:
This patch removes the unused EXPORT_SYMBOL(icmpmsg_statistics).
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
4ce74657ac0b1bdcb4c7bc359d05643f8cc4a08b
diff --git a/net/ipv4/icmp.c b/net/ipv4/icmp.c
index 272c69e..233de06 100644
[EMAIL PROTECTED] wrote on 10/24/2007 12:14:37 PM:
On Wed, Oct 24, 2007 at 12:07:45PM -0700, David Stevens wrote:
[EMAIL PROTECTED] wrote on 10/24/2007 09:24:10 AM:
This patch removes the unused EXPORT_SYMBOL(icmpmsg_statistics).
Signed-off-by: Adrian Bunk [EMAIL PROTECTED
I took a look at the DCCP references, and I think they're just
incrementing the wrong MIB variable -- e.g., it's incrementing
ICMP_MIB_INERRORS when the skb length is less than the
header indicates. That's not an ICMP_MIB_INERRORS error,
that's an IPSTATS_MIB_INHDRERRORS error. ICMP_MIB_INERRORS
My bad -- I see what it's doing, and it looks ok after all.
I thought I saw an INMSGS (but didn't). These are ICMP errors that
went through icmp_rcv() and were counted correctly before getting
to the protocol error handlers. These are failures due mostly to not
having enough, or the right
I don't know about a new knob, but it's the same notion
as rp_filter, so why not use rpf for RTN_LOCAL types?
Ie, allow RTN_LOCAL and RTN_UNICAST at the top, but
check rpf if the devs aren't equal or RTN_LOCAL
It seems like not a good thing to rely on in the first place, though;
usually
From looking at the code, it appears that validate
source is failing just because of the rp_filter. Do you have
rp_filter set to nonzero?
If so, it may do what you want just by setting that
to 0:
sysctl -w net.ipv4.conf.all.rp_filter=0
I don't know why you'd want it to be different for multicasting. If you
want to hear your own multicasts, you should use MULTICAST_LOOP;
hearing them off the wire indicates all the same bad things -- a forger,
a duplicate address or a routing loop. Those aren't any better for
multicasting than
[EMAIL PROTECTED] wrote on 10/19/2007 04:43:27 AM:
Vlad Yasevich [EMAIL PROTECTED] wrote:
Now, to figure out what IPv6 does different and why it works.
Seems to me that the two should have the same behavior.
IPv6 on Linux uses a per-interface addressing model as opposed
to the per-host
Acked-by: David L Stevens [EMAIL PROTECTED]
Signed-off-by: Pavel Emelyanov [EMAIL PROTECTED]
---
diff --git a/net/ipv6/af_inet6.c b/net/ipv6/af_inet6.c
index bc92938..1b1caf3 100644
--- a/net/ipv6/af_inet6.c
+++ b/net/ipv6/af_inet6.c
@@ -747,6 +747,7 @@ static void
I'm not clear on your configuration.
Are the sender and receiver running on the same machine? Are
you saying eth0 and eth1 are connected on the same link?
+-DLS
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to
Can you send the contents of /proc/net/igmp and the packet trace,
also? And the code?
+-DLS
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
You're joining the group on interface eth1, which is the
sender, right? You need to be a member on eth0 to receive it
there. I think your program needs another argument, to
specify the receiving interface, which you want to be
different from the sending interface.
If you have icmp_echo_ignore_broadcasts set to 1, it won't respond to
multicasts. That should be all you need to do for 224.0.0.1.
Some smart switches rely on IGMP snooping to determine group membership,
and some of those don't understand IGMPv3, so if you have no v1 or v2
queriers
on the
hmm maybe I misunderstand here, but the we are trying to make OSPF work
in 2.6 and the problem appears to be that our board does not pick up
multicasts.
Is icmp_echo_ignore_broadcasts=0 required to make OSPF work in 2.6?
Jocke
No, it's required to make ping to a multicast
dev_mcast and igmp looks:
[EMAIL PROTECTED]:/proc/net# m dev_mcast
1eth01 0 01005e01
2eth11 0 01005e01
These are the hardware multicast addresses for
224.0.0.1 (so, correct).
[EMAIL PROTECTED]:/proc/net# m igmp
Idx Device
Acked-by: David L Stevens [EMAIL PROTECTED]
Signed-off-by: Brian Haley [EMAIL PROTECTED]
diff --git a/net/ipv6/ipv6_sockglue.c b/net/ipv6/ipv6_sockglue.c
index 532425d..1334fc1 100644
--- a/net/ipv6/ipv6_sockglue.c
+++ b/net/ipv6/ipv6_sockglue.c
@@ -539,12 +539,15 @@ done:
case
Questions of this sort should normally be directed to linux-net mailing
list.
From the code you quoted, I see at least one case where it
will fail -- when the allocated buffer you pass to recvmsg is smaller than
value (ie. the datagram is too big for the read buffer).
If that's not the problem,
What about just checking for 0 in the later test?
if (val __dev_get_by_index(val) == NULL) {
...
+-DLS
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Brian Haley [EMAIL PROTECTED] wrote on 10/10/2007 02:20:45 PM:
David Stevens wrote:
What about just checking for 0 in the later test?
if (val __dev_get_by_index(val) == NULL) {
We could fail the next check right before that though:
Right, the semantics there would
Sorry if this is a dumb question, but what is the model you intend for
SNMP? Do you want each namespace to be its own virtual machine with
its own, separate MIB?
Ifindex's have to uniquely identify the interface (virtual or otherwise)
to remote
queriers (not just local applications), so unless
Dmitry,
Good catch; a couple comments:
struct ipv6_pinfo *np = inet6_sk(sk);
int err;
+ int addr_type = ipv6_addr_type(addr);
+
+ if (addr_type == IPV6_ADDR_MAPPED) {
+ __be32 v4addr = addr-s6_addr32[3];
+ struct ip_mreqn mreq;
+
Brian,
ipv6_addr_type() returns a mask, so checking for equality will
fail to
match if any other (irrelevant) attributes are set. How about using
bitwise
operators for that? Also, the error message is no longer descriptive of
the
failure if it's a link-local multicast, but you could
Brian,
I don't think a few instructions is a performance issue in the
redirect
paths (it'd be pretty broken if you're getting or generating lots of
them), but I
know there are lots of other checks similar to that that will break with
new
attributes, so doing that as a general clean-up
Brian,
A multicast address should never be the target of a neighbor
discovery request; the sender should use the mapping function for all
multicasts. So, I'm not sure that your example can ever happen, and it
certainly is ok to send ICMPv6 errors to multicast addresses in general.
But I
I'm not sure why it's using rt_src here, but there are relevant cases that
your description doesn't cover. For example, what happens if the source
is not set in the original packet? Does NAT affect this?
You quote RFC text for ICMP echo and the case where the receiving machine
is the final
Dave,
Thanks. That rev2 was for v6-only; I didn't see anythng about the
v4 patch (below, in case it fell through the cracks).
+-DLS
- Forwarded by David Stevens/Beaverton/IBM on 09/16/2007 09:02 PM
-
David Stevens
Background: RFC 4293 deprecates existing individual, named ICMP
type counters to be replaced with the ICMPMsgStatsTable. This table
includes entries for both IPv4 and IPv6, and requires counting of all
ICMP types, whether or not the machine implements the type.
These patches remove (but not
Yoshifuji Hideaki [EMAIL PROTECTED] wrote on 09/11/2007 01:50:53
AM:
Dave, we've been supporting per-interface stats for IPv6, and
you seem to remove them. Please keep them. Thank you.
The reason I didn't for ICMPMsgStats is the size. The RFC requires
in out counters for all types,
Background: RFC 4293 deprecates existing individual, named ICMP
type counters to be replaced with the ICMPMsgStatsTable. This table
includes entries for both IPv4 and IPv6, and requires counting of all
ICMP types, whether or not the machine implements the type.
These patches remove (but not
Background: RFC 4293 deprecates existing individual, named ICMP
type counters to be replaced with the ICMPMsgStatsTable. This table
includes entries for both IPv4 and IPv6, and requires counting of all
ICMP types, whether or not the machine implements the type.
These patches remove (but not
Stephen Hemminger [EMAIL PROTECTED] wrote on 08/24/2007
08:52:03 AM:
You need hardware support for deferred interrupts. Most devices have it
(e1000, sky2, tg3)
and it interacts well with NAPI. It is not a generic thing you want done
by the stack,
you want the hardware to hold off
Oliver Hartkopp [EMAIL PROTECTED] wrote on 07/23/2007 11:22:39 PM:
When you like to create any timeout based on your calculated value, you
might run into the problem that your calculated value is set to _zero_
even if there was some time before the conversion. This might probably
not what you
sockets that join different groups receive messages from the respective
other group (if they are only bound to the wildcard address). Obviously
this is handled differently in Linux for IPv4, where the socket matching
for incoming message is done solely on the 4-tuple of addresses and
I think #2 in your list is the right choice, and that has nothing to do
with adding a
non-standard option (which I completely agree is a bad idea).
It looked like you're just checking if the machine is acting as a router
or not and
if it comes from a link-local address; is that right? Of
Since you asked for another idea, how about using netlink to send
_validated_ RA
information to interested parties?
-vlad
That sounds like a good idea to me (FWIW),
though I also still think a simple raw-socket
application would do it just fine, possibly with
no kernel modification
I think there's a more general problem that's a huge hassle. There are
lots of
new SNMP MIB's, but no conventions (that I'm aware of, at least) to allow
for
changes to the /proc entries that get them to applications. For example,
the
route age data recently submitted. I agree that existing apps
Unrelated wishful thinking
I keep having hopeful dreams that one day netfilter will grow support
for cross-protocol NAT (IE: NAT a TCPv4 connection over TCPv6 to the
IPv6-only local web server, or vice versa). It would seem that would
require a merged xtables program.
You don't
[EMAIL PROTECTED] wrote on 06/23/2007 07:47:06 AM:
Rémi and Simon give my responses very eloquently. Although you could
have yet-another-network-daemon redundantly process RA messages, the
kernel is doing it already and it makes sense to just push this
It would be two pieces looking
Rémi Denis-Courmont [EMAIL PROTECTED] wrote on 06/23/2007 09:51:55
AM:
How do I authenticate SeND RA? How do I deal with the link going down
before the expiration? How do I know this interface is doing autoconf
at all?
The kernel should do the authentication, as it will for other
Rémi Denis-Courmont [EMAIL PROTECTED] wrote on 06/23/2007 11:13:01
AM:
An implementation might perform additional validity checks on the
ICMPv6 message content and discard malformed packets. However, a
portable application must not assume that such validity checks have
been
Scott,
Why not make the application that writes resolv.conf
also listen on a raw ICMPv6 socket? I don't believe you'd need
any kernel changes, then, and it seems pretty simple and
straightforward.
+-DLS
-
To unsubscribe from this list: send the
[EMAIL PROTECTED] wrote on 06/22/2007 06:17:46 PM:
On 23/06/07 02:04, David Stevens wrote:
Why not make the application that writes resolv.conf
also listen on a raw ICMPv6 socket? I don't believe you'd need
any kernel changes, then, and it seems pretty simple and
straightforward
Arthur,
I assume you're making use of the hack mentioned in route.c:
... This hack is not just for fun, it allows vic, vat and friends to
work.
They bind socket to loopback, set ttl to zero and expect that it will
work.
I don't know the details of the intent for this hack, but
Your patch looks correct to me.
+-DLS
Signed-off-by: David L Stevens [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote on 05/12/2007 03:51:35 PM:
From: Corey Mutter [EMAIL PROTECTED]
Reverse the sense of the promiscuous-mode tests in ip6_mc_input().
Signed-off-by: Corey
The word small is coming up a lot in this discussion, and
I think packet size really has nothing to do with it. Multiple
streams generating packets of any size would benefit; the
key ingredient is a queue length greater than 1.
I think the intent is to remove queue lock cycles by taking
the whole
Which worked _very_ well (the whole list) going in the other direction
for the
netisr queue(s) in HP-UX 10.20. OK, I promise no more old HP-UX stories
for the
balance of the week :)
Yes, OSes I worked on in other lives usually took the whole queue
and then took responsibility for
When an IPv6 router is forwarding a packet with a link-local scope source
address off-link, RFC 4007 requires it to send an ICMPv6 destination
unreachable with code 2 (not neighbor), but Linux doesn't. Fix below.
+-DLS
[in-line for viewing, attached
It looks to me like rejoin is essentially ip_mc_up(), and it'd be better
to call that than add a nearly identical function.
Also, real interfaces already do gratuitous IGMP advertisements when
they are bounced (the reason there is an ip_mc_up()). Could bonding,
when failing over, simply mark the
[EMAIL PROTECTED] wrote on 03/06/2007 03:15:41 PM:
David Stevens [EMAIL PROTECTED] wrote:
It looks to me like rejoin is essentially ip_mc_up(), and it'd be
better
to call that than add a nearly identical function.
Won't ip_mc_up() acquire an additional reference (via
Marking the master down would, I believe, issue notifiers that
the device has gone down. Various things, network manager sort of
applications in particular, listen to those, so I'm not sure it's a
good
idea. I think there are other side effects as well, I'm thinking it
would flush
Reading /proc/net/anycast6 when there is no anycast address
on an interface results in an ever-increasing inet6_dev reference
count, as well as a reference to the netdevice you can't get rid of.
Patch below attached.
+-DLS
Signed-off-by: David L
Alexey,
I think you're correct-- looks like it needs:
if (!skb)
return NULL;
just before the skb_put(), since an allocation (and failure)
could occur in either the igmpv3_newpack() call or in add_grhead().
Also, similar code in net/ipv6/mcast..c.
Yeah, sure.
+-DLS
Acked-by: David L Stevens [EMAIL PROTECTED]
Signed-off-by: Jarek Poplawski [EMAIL PROTECTED]
---
diff -Nurp linux-2.6.20-rc3-/net/ipv4/devinet.c
linux-2.6.20-rc3/net/ipv4/devinet.c
--- linux-2.6.20-rc3-/net/ipv4/devinet.c 2007-01-05
Ben Jarek,
Your analysis looks correct to me. It seems to me the problem is
that
we don't want the in_device to be searchable until after the
initialization is done.
What about moving the initialization of dev-ip_ptr in inetdev_init() to
after the
out label?
Ben,
Here's a patch that I think will fix it, assuming the receive is
on the
same device as the initialization. Can you try this out?
+-DLS
[inline for viewing, attached for applying]
Signed-off-by: David L Stevens [EMAIL PROTECTED]
diff
OK, sounds good.
By the way, I think you can probably hit it more often if you have
something on the virtual network sending lots of multicast traffic while
you're creating the interface. That'll increase the odds that you'll
get into ip_check_mc() with a partially initialized in_dev.
You can
Herbert,
You're right, I don't know whether it'll fix the problem Ben saw
or not, but it looks like the original code can do a receive before the
in_device is fully initialized, and that, of course, is bad.
If the device for ip_rcv() is not the same one we were
initializing when
Ben,
If the ip_rcv() and the inetdev_init() are on the same
interface in your stack backtrace, it's a certainty at that point
that the lock value is still 0ed, because none of the initialization
occurs until after it has returned from the function it interrupted
to do the receive.
I've looked at this a little too -- it'd be nice to know who holds
the write lock.
I see ip_mc_destroy_dev() is bouncing through the lock for
each multicast address, though it starts at the beginning of
the list each time. I don't see a problem with it, but it'd be
simpler if it acquired the
The IGMPV3_EXP() macro doesn't correctly shift the normalization bit, so
time-out values are longer than they should be. Patch below for viewing
and attached for applying.
Thanks to Dirk Ooms for finding the problem in IGMPv3 - MLDv2 had a
similar problem that was already fixed a year ago. :-(
David Miller [EMAIL PROTECTED] wrote on 11/13/2006 04:50:58 PM:
Puzzling :-) Then why is the transformation only performed for
UDP in the ipv4 stack? It seems by your logic TCP would need
to either do the if (sum==0) sum=~0; thing or it would need
to accept both 0 and ~0 in the checksum
Sorry, I saw this discussion a little late...
The Internet checksum is defined as a 1's-complement sum, so if the
alternate 0 does not have a special meaning in a protocol, then by
1's-complement arithmetic, 0 == ~0.
So, it looks to me without the remapping that a valid checksum
may also
If the index is set, it doesn't look up the address (which may be
expensive).
If you want to look up by address, the index must be 0.
I wouldn't call that a bug.
+-DLS
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a
Alexey Kuznetsov [EMAIL PROTECTED] wrote on 09/14/2006 03:30:37 AM:
Hello!
No, it returns 1 (allow) if there are no filters to explicitly
filter it. I wrote that code. :-)
I see. It did not behave this way old times.
From your mails I understood that current behaviour matches
[EMAIL PROTECTED] wrote on 09/13/2006 07:13:55 AM:
Only
the socket that is bound to the group address to which the packet was
sent should get it.
This is not true on any OS I'm aware of, including the
original sockets multicast implementation on early BSD.
Multicast group
Jeff Layton [EMAIL PROTECTED] wrote on 09/13/2006 09:12:23 AM:
Most of the RFC's I've looked at don't seem to have much to say about
how multicasting works at the socket level. Is there an RFC or
specification that spells this out, or is this one of those situations
where things are somewhat
Alexey Kuznetsov [EMAIL PROTECTED] wrote on 09/13/2006 01:20:29 PM:
Hello!
IPv6 behaves the same way.
Actually, Linux IPv6 filters received multicasts, inet6_mc_check() does
this.
No, it returns 1 (allow) if there are no filters to explicitly
filter it. I wrote that code. :-)
Michal,
My question/suggestion:
Would it feasible to drop the relevant entries from sockets' multicast
membership lists on the interface
delete?
Yes, I think this is needed. The original BSD code didn't have
this
problem because it didn't support removal of a device. I wondered for
Michal Ruzicka [EMAIL PROTECTED] wrote on 08/17/2006 05:26:35
AM:
I've reviewed your patch (the IPv4 part of it) and I think I can say
that
our soulutions are actually quite similar.
But I can come up with one difference that I'd like know your opinion
on.
If you have a duplicated
Michal,
I believe the patch I submitted yesterday fixes this
problem, and in a simpler way.
+-DLS
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Here's a patch to fix source filter leakage when a device is removed
and a process leaves the group thereafter. (2nd part of prior discussion)
This patch also includes corresponding fixes for IPv6 multicast source
filters on device removal (1st 2nd parts of prior discussion, for IPv6).
1 - 100 of 122 matches
Mail list logo
