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
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 unreachable
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: imr_ifin
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 ar
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 interfac
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]>
[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 w
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
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 PROTECTE
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
> namespac
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 it's
>
> 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 a
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))
> >
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 ch
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_type&IPV6_ADDR_LINKLOCAL) {
if (addr_len >= sizeof(struct sockaddr_in6)) {
if (sk->sk_bound_dev_if && usin->sin6_scope_id &&
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
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:
>
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
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 li
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
> 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
> 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*. :-)
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, maybe
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/200
> 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 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 yo
[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
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 PROTECTE
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 code.
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 protoco
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
is
[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).
> > >
> &g
[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 1
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 receiv
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
+-DLS
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 they
[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 t
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.
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 http://vger.kernel.org/majo
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 t
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 cleanup
> 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 De
>
> 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 multi
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 network
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 proble
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:
>
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 t
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 htt
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 yo
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 se
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 mak
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;
> + mreq.imr_multiad
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 don
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 desti
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 St
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 real
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 ty
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 real
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 real
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 i
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 w
> 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
p
> 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 modificati
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 course,
[EMAIL PROTECTED] wrote on 06/29/2007 10:30:23 AM:
> David Stevens <[EMAIL PROTECTED]> writes:
>
> > 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 o
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
>
> 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 actually need it (at
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
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 o
[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 lookin
[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,
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 line
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-b
> 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 fo
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 whol
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, attache
> >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
> > wo
[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&#
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
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.
W
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 11:53:16
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.
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 the
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 use
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
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?
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 write
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
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 m
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 behavi
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
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 some
[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 m
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
"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 dupli
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 http://vger.k
1 - 100 of 129 matches
Mail list logo
