linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* IPv6 multicast forwarding
@ 2008-10-23 22:11 Todd Hayton
  2008-10-24  9:10 ` Alejandro Riveira Fernández
  0 siblings, 1 reply; 6+ messages in thread
From: Todd Hayton @ 2008-10-23 22:11 UTC (permalink / raw)
  To: linux-kernel

Let me apologize in advance for the length of this message - it is long!

I'm trying to test out IPv6 multicast forwarding on a 2.6.26 kernel
and I'm getting some strange values for the upcall messages from the
kernel. My code is below, but to give an overview, my setup is as
follows:

    sender ------ ff15::1 -----> [eth1] linux 2.6.26 [eth0] ------> ...

So my incoming interface is eth1 and my outgoing interface is eth0 and
I am sending traffic to IPv6 multicast group ff15::1

I am seeing that mifs are being created successfully:

[root@localhost mcast-tools]# cat /proc/net/ip6_mr_vif
Interface      BytesIn  PktsIn  BytesOut PktsOut Flags
 1 eth1              0       0         0       0 00000
 2 eth0              0       0         0       0 00000

And after I start sending traffic I can see that the kernel is
queueing the packets (as it does not yet have a route installed for
this traffic):

[root@localhost mcast-tools]# cat /proc/net/ip6_mr_cache
Group                            Origin                           Iif
    Pkts  Bytes     Wrong  Oifs
ff15:0000:0000:0000:0000:0000:0000:0001
fec0:0000:0000:0000:0000:0000:0000:0001 65535     1028        4
0

Which is where my code comes in, I am monitoring a raw ICMPV6 socket
so as to receive the kernel upcalls for this traffic. Now, I am
expecting to get a message from the kernel that "appears" to be an MLD
header but is in reality an mrt6msg, the flag being that the icmp6
type is set to 0 so as to indicate to the userland process that this
is an upcall.

However, in my code after I've detected that the raw socket is
readable and I read from it, I never really seem to get data that
looks like an mld_hdr:

...
      n = read(raw_icmpv6_sock, raw_recv_buf, sizeof(raw_recv_buf));
      if (n < 0) {
        perror("read: ");
        exit(1);
      }
     mh = (struct mld_hdr *)raw_recv_buf;
    if (mh->mld_icmp6_hdr.icmp6_type == 0) { /* kernel upcall */
...

Except the icmp6_type is *never* 0 - instead it's an assortment of
strange values.

I fired up gdb, examined the contents of raw_recv_buf, right after
read() occurs and mh is set to point to raw_recv_buf:

(gdb) p/x raw_recv_buf[0]@n
$13 = {0x20, 0x0, 0x80, 0x1, 0x20, 0x0, ....
(gdb) p/d mh->mld_icmp6_hdr.icmp6_type
$14 = 32

and then the next packet comes in with different values..

(gdb) p/x raw_recv_buf[0]@n
$15 = {0x86, 0x15, 0x60, 0x1, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
0xc2, 0x3, 0x18, 0x0, 0x95, 0x1a, 0x7, 0x0, 0x3, 0x15, 0x60, 0x1,
0x86, 0x15, 0x60, 0x1, 0xec, 0x\
ec, 0xe9, 0xe9, 0xe9, 0xe9, 0xff, 0xff, 0x0, 0x0, 0x0, 0x0}
(gdb) p/d mh->mld_icmp6_hdr.icmp6_type
$16 = 134

Now I am examining the traffic sent in another window:

[root@localhost linux]# tcpdump -xnnevi eth1
tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
17:59:50.713520 08:00:27:9c:aa:88 > 33:33:00:00:00:01, ethertype IPv6
(0x86dd), length 66: (hlim 3, next-header UDP (17) payload length: 12)
fec0::1.40825 > ff15::1.31337: [udp sum ok] UDP, length 4
	0x0000:  6000 0000 000c 1103 fec0 0000 0000 0000
	0x0010:  0000 0000 0000 0001 ff15 0000 0000 0000
	0x0020:  0000 0000 0000 0001 9f79 7a69 000c 2354
	0x0030:  6162 6364
17:59:51.725815 08:00:27:9c:aa:88 > 33:33:00:00:00:01, ethertype IPv6
(0x86dd), length 66: (hlim 3, next-header UDP (17) payload length: 12)
fec0::1.40825 > ff15::1.31337: [udp sum ok] UDP, length 4
	0x0000:  6000 0000 000c 1103 fec0 0000 0000 0000
	0x0010:  0000 0000 0000 0001 ff15 0000 0000 0000
	0x0020:  0000 0000 0000 0001 9f79 7a69 000c 2354
	0x0030:  6162 6364

So either I'm misunderstanding the upcall mechanism here (most likely)
or there's a bug... If there's any other information I can include let
me know. Below is the code I am using to monitor the raw socket - it's
not pretty code :-) just what I am using for testing right now!

Todd H

#include <stdio.h>
#include <stdlib.h>
#include <strings.h>
#include <errno.h>

#include <sys/types.h>
#include <sys/uio.h>
#include <sys/socket.h>
#include <sys/select.h>
#include <sys/param.h>

#include <net/route.h>

#include <netinet/in.h>
#include <netinet/ip6.h>
#include <netinet/icmp6.h>
#include <linux/mroute6.h>

#include <arpa/inet.h>

#include <unistd.h>

#define IVIF 1
#define OVIF 2

static int raw_icmpv6_sock = -1;
static char raw_recv_buf[8192];

int raw_sock_init()
{
  struct icmp6_filter filt;

  raw_icmpv6_sock = socket(AF_INET6, SOCK_RAW, IPPROTO_ICMPV6);
  if (raw_icmpv6_sock < 0) {
    perror("socket: ");
    return -1;
  }

  ICMP6_FILTER_SETBLOCKALL(&filt);
  if (setsockopt(raw_icmpv6_sock, IPPROTO_ICMPV6, ICMP6_FILTER, &filt,
sizeof(filt)) < 0) {
    perror("setsockopt ICMP6_FILTER");
    return -1;
  }

  return 0;
}

int mrt6_init()
{
  int v;

  if (raw_sock_init() < 0)
    return -1;

  v = 1;
  if (setsockopt(raw_icmpv6_sock, IPPROTO_IPV6, MRT6_INIT,
		 (void *)&v, sizeof(int)) < 0) {
    perror("setsockopt: ");
    return -1;
  }
  return 0;
}

int mrt6_done()
{
  int v;
  v = 1;
  if (setsockopt(raw_icmpv6_sock, IPPROTO_IP, MRT6_DONE,
		 (void *)&v, sizeof(int)) < 0) {
    perror("setsockopt: ");
    return -1;
  }
  return 0;
}

int mrt6_add_mfc(struct sockaddr_in6 src, struct sockaddr_in6 grp)
{
  struct mf6cctl mc;

  bzero(&mc, sizeof(mc));
  mc.mf6cc_origin     = src;
  mc.mf6cc_mcastgrp   = grp;
  mc.mf6cc_parent     = IVIF;

  IF_ZERO(&mc.mf6cc_ifset);
  IF_SET(OVIF, &mc.mf6cc_ifset);

  if (setsockopt(raw_icmpv6_sock, IPPROTO_IPV6, MRT6_ADD_MFC,
		 (void *)&mc, sizeof(mc))) {
    perror("setsockopt: ");
    return -1;
  }

  return 0;
}

int mrt6_add_mif()
{
  struct mif6ctl mc;

  bzero(&mc, sizeof(mc));

  mc.mif6c_mifi = IVIF;
  mc.mif6c_pifi = 3;

  if (setsockopt(raw_icmpv6_sock, IPPROTO_IPV6, MRT6_ADD_MIF,
		 (void *)&mc, sizeof(mc))) {
    perror("setsockopt: ");
    return -1;
  }

  bzero(&mc, sizeof(mc));

  mc.mif6c_mifi = OVIF;
  mc.mif6c_pifi = 2;

  if (setsockopt(raw_icmpv6_sock, IPPROTO_IPV6, MRT6_ADD_MIF,
		 (void *)&mc, sizeof(mc))) {
    perror("setsockopt: ");
    return -1;
  }
  return 0;
}

int main()
{
  if (mrt6_init() < 0)
    exit(1);

  if (mrt6_add_mif() < 0)
    exit(1);

  /* wait for upcall */
  while (1) {
    int              n      = 0;
    fd_set           rset;
    struct mld_hdr * mh     = NULL;
    struct mrt6msg * upcall = NULL;

    FD_ZERO(&rset);
    FD_SET(raw_icmpv6_sock, &rset);

    n = select(raw_icmpv6_sock + 1, &rset, NULL, NULL, NULL);
    if (n < 0) {
      perror("select: ");
      exit(1);
    }

    n = read(raw_icmpv6_sock, raw_recv_buf, sizeof(raw_recv_buf));
    if (n < 0) {
      perror("read: ");
      exit(1);
    }
    mh = (struct mld_hdr *)raw_recv_buf;
    if (mh->mld_icmp6_hdr.icmp6_type == 0) { /* kernel upcall */
      upcall = (struct mrt6msg *)raw_recv_buf;
      if (upcall->im6_msgtype == MRT6MSG_NOCACHE) {
	char sbuf[64], dbuf[64];
	struct sockaddr_in6 src, grp;
	fprintf(stderr, "(%s,%s)\n",
		inet_ntop(AF_INET6, &upcall->im6_src, sbuf, sizeof(sbuf)),
		inet_ntop(AF_INET6, &upcall->im6_dst, dbuf, sizeof(dbuf)));	

	bzero(&src, sizeof(src));
	bzero(&grp, sizeof(grp));

	src.sin6_addr = upcall->im6_src;
	grp.sin6_addr = upcall->im6_dst;

	mrt6_add_mfc(src, grp);
      }
    }

  }
  if (mrt6_done() < 0)
    exit(1);

  exit(0);
}

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: IPv6 multicast forwarding
  2008-10-23 22:11 IPv6 multicast forwarding Todd Hayton
@ 2008-10-24  9:10 ` Alejandro Riveira Fernández
  2008-10-24 10:12   ` Pekka Savola
  0 siblings, 1 reply; 6+ messages in thread
From: Alejandro Riveira Fernández @ 2008-10-24  9:10 UTC (permalink / raw)
  To: Todd Hayton; +Cc: linux-kernel, netdev

El Thu, 23 Oct 2008 18:11:50 -0400
"Todd Hayton" <todd.hayton@gmail.com> escribió:


  [ CCing netdev@vger.kernel.org ]


> Let me apologize in advance for the length of this message - it is long!
> 
> I'm trying to test out IPv6 multicast forwarding on a 2.6.26 kernel
> and I'm getting some strange values for the upcall messages from the
> kernel. My code is below, but to give an overview, my setup is as
> follows:
> 
>     sender ------ ff15::1 -----> [eth1] linux 2.6.26 [eth0] ------> ...
> 
> So my incoming interface is eth1 and my outgoing interface is eth0 and
> I am sending traffic to IPv6 multicast group ff15::1
> 
> I am seeing that mifs are being created successfully:
> 
> [root@localhost mcast-tools]# cat /proc/net/ip6_mr_vif
> Interface      BytesIn  PktsIn  BytesOut PktsOut Flags
>  1 eth1              0       0         0       0 00000
>  2 eth0              0       0         0       0 00000
> 
> And after I start sending traffic I can see that the kernel is
> queueing the packets (as it does not yet have a route installed for
> this traffic):
> 
> [root@localhost mcast-tools]# cat /proc/net/ip6_mr_cache
> Group                            Origin                           Iif
>     Pkts  Bytes     Wrong  Oifs
> ff15:0000:0000:0000:0000:0000:0000:0001
> fec0:0000:0000:0000:0000:0000:0000:0001 65535     1028        4
> 0
> 
> Which is where my code comes in, I am monitoring a raw ICMPV6 socket
> so as to receive the kernel upcalls for this traffic. Now, I am
> expecting to get a message from the kernel that "appears" to be an MLD
> header but is in reality an mrt6msg, the flag being that the icmp6
> type is set to 0 so as to indicate to the userland process that this
> is an upcall.
> 
> However, in my code after I've detected that the raw socket is
> readable and I read from it, I never really seem to get data that
> looks like an mld_hdr:
> 
> ...
>       n = read(raw_icmpv6_sock, raw_recv_buf, sizeof(raw_recv_buf));
>       if (n < 0) {
>         perror("read: ");
>         exit(1);
>       }
>      mh = (struct mld_hdr *)raw_recv_buf;
>     if (mh->mld_icmp6_hdr.icmp6_type == 0) { /* kernel upcall */
> ...
> 
> Except the icmp6_type is *never* 0 - instead it's an assortment of
> strange values.
> 
> I fired up gdb, examined the contents of raw_recv_buf, right after
> read() occurs and mh is set to point to raw_recv_buf:
> 
> (gdb) p/x raw_recv_buf[0]@n
> $13 = {0x20, 0x0, 0x80, 0x1, 0x20, 0x0, ....
> (gdb) p/d mh->mld_icmp6_hdr.icmp6_type
> $14 = 32
> 
> and then the next packet comes in with different values..
> 
> (gdb) p/x raw_recv_buf[0]@n
> $15 = {0x86, 0x15, 0x60, 0x1, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
> 0xc2, 0x3, 0x18, 0x0, 0x95, 0x1a, 0x7, 0x0, 0x3, 0x15, 0x60, 0x1,
> 0x86, 0x15, 0x60, 0x1, 0xec, 0x\
> ec, 0xe9, 0xe9, 0xe9, 0xe9, 0xff, 0xff, 0x0, 0x0, 0x0, 0x0}
> (gdb) p/d mh->mld_icmp6_hdr.icmp6_type
> $16 = 134
> 
> Now I am examining the traffic sent in another window:
> 
> [root@localhost linux]# tcpdump -xnnevi eth1
> tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
> 17:59:50.713520 08:00:27:9c:aa:88 > 33:33:00:00:00:01, ethertype IPv6
> (0x86dd), length 66: (hlim 3, next-header UDP (17) payload length: 12)
> fec0::1.40825 > ff15::1.31337: [udp sum ok] UDP, length 4
> 	0x0000:  6000 0000 000c 1103 fec0 0000 0000 0000
> 	0x0010:  0000 0000 0000 0001 ff15 0000 0000 0000
> 	0x0020:  0000 0000 0000 0001 9f79 7a69 000c 2354
> 	0x0030:  6162 6364
> 17:59:51.725815 08:00:27:9c:aa:88 > 33:33:00:00:00:01, ethertype IPv6
> (0x86dd), length 66: (hlim 3, next-header UDP (17) payload length: 12)
> fec0::1.40825 > ff15::1.31337: [udp sum ok] UDP, length 4
> 	0x0000:  6000 0000 000c 1103 fec0 0000 0000 0000
> 	0x0010:  0000 0000 0000 0001 ff15 0000 0000 0000
> 	0x0020:  0000 0000 0000 0001 9f79 7a69 000c 2354
> 	0x0030:  6162 6364
> 
> So either I'm misunderstanding the upcall mechanism here (most likely)
> or there's a bug... If there's any other information I can include let
> me know. Below is the code I am using to monitor the raw socket - it's
> not pretty code :-) just what I am using for testing right now!
> 
> Todd H
> 
> #include <stdio.h>
> #include <stdlib.h>
> #include <strings.h>
> #include <errno.h>
> 
> #include <sys/types.h>
> #include <sys/uio.h>
> #include <sys/socket.h>
> #include <sys/select.h>
> #include <sys/param.h>
> 
> #include <net/route.h>
> 
> #include <netinet/in.h>
> #include <netinet/ip6.h>
> #include <netinet/icmp6.h>
> #include <linux/mroute6.h>
> 
> #include <arpa/inet.h>
> 
> #include <unistd.h>
> 
> #define IVIF 1
> #define OVIF 2
> 
> static int raw_icmpv6_sock = -1;
> static char raw_recv_buf[8192];
> 
> int raw_sock_init()
> {
>   struct icmp6_filter filt;
> 
>   raw_icmpv6_sock = socket(AF_INET6, SOCK_RAW, IPPROTO_ICMPV6);
>   if (raw_icmpv6_sock < 0) {
>     perror("socket: ");
>     return -1;
>   }
> 
>   ICMP6_FILTER_SETBLOCKALL(&filt);
>   if (setsockopt(raw_icmpv6_sock, IPPROTO_ICMPV6, ICMP6_FILTER, &filt,
> sizeof(filt)) < 0) {
>     perror("setsockopt ICMP6_FILTER");
>     return -1;
>   }
> 
>   return 0;
> }
> 
> int mrt6_init()
> {
>   int v;
> 
>   if (raw_sock_init() < 0)
>     return -1;
> 
>   v = 1;
>   if (setsockopt(raw_icmpv6_sock, IPPROTO_IPV6, MRT6_INIT,
> 		 (void *)&v, sizeof(int)) < 0) {
>     perror("setsockopt: ");
>     return -1;
>   }
>   return 0;
> }
> 
> int mrt6_done()
> {
>   int v;
>   v = 1;
>   if (setsockopt(raw_icmpv6_sock, IPPROTO_IP, MRT6_DONE,
> 		 (void *)&v, sizeof(int)) < 0) {
>     perror("setsockopt: ");
>     return -1;
>   }
>   return 0;
> }
> 
> int mrt6_add_mfc(struct sockaddr_in6 src, struct sockaddr_in6 grp)
> {
>   struct mf6cctl mc;
> 
>   bzero(&mc, sizeof(mc));
>   mc.mf6cc_origin     = src;
>   mc.mf6cc_mcastgrp   = grp;
>   mc.mf6cc_parent     = IVIF;
> 
>   IF_ZERO(&mc.mf6cc_ifset);
>   IF_SET(OVIF, &mc.mf6cc_ifset);
> 
>   if (setsockopt(raw_icmpv6_sock, IPPROTO_IPV6, MRT6_ADD_MFC,
> 		 (void *)&mc, sizeof(mc))) {
>     perror("setsockopt: ");
>     return -1;
>   }
> 
>   return 0;
> }
> 
> int mrt6_add_mif()
> {
>   struct mif6ctl mc;
> 
>   bzero(&mc, sizeof(mc));
> 
>   mc.mif6c_mifi = IVIF;
>   mc.mif6c_pifi = 3;
> 
>   if (setsockopt(raw_icmpv6_sock, IPPROTO_IPV6, MRT6_ADD_MIF,
> 		 (void *)&mc, sizeof(mc))) {
>     perror("setsockopt: ");
>     return -1;
>   }
> 
>   bzero(&mc, sizeof(mc));
> 
>   mc.mif6c_mifi = OVIF;
>   mc.mif6c_pifi = 2;
> 
>   if (setsockopt(raw_icmpv6_sock, IPPROTO_IPV6, MRT6_ADD_MIF,
> 		 (void *)&mc, sizeof(mc))) {
>     perror("setsockopt: ");
>     return -1;
>   }
>   return 0;
> }
> 
> int main()
> {
>   if (mrt6_init() < 0)
>     exit(1);
> 
>   if (mrt6_add_mif() < 0)
>     exit(1);
> 
>   /* wait for upcall */
>   while (1) {
>     int              n      = 0;
>     fd_set           rset;
>     struct mld_hdr * mh     = NULL;
>     struct mrt6msg * upcall = NULL;
> 
>     FD_ZERO(&rset);
>     FD_SET(raw_icmpv6_sock, &rset);
> 
>     n = select(raw_icmpv6_sock + 1, &rset, NULL, NULL, NULL);
>     if (n < 0) {
>       perror("select: ");
>       exit(1);
>     }
> 
>     n = read(raw_icmpv6_sock, raw_recv_buf, sizeof(raw_recv_buf));
>     if (n < 0) {
>       perror("read: ");
>       exit(1);
>     }
>     mh = (struct mld_hdr *)raw_recv_buf;
>     if (mh->mld_icmp6_hdr.icmp6_type == 0) { /* kernel upcall */
>       upcall = (struct mrt6msg *)raw_recv_buf;
>       if (upcall->im6_msgtype == MRT6MSG_NOCACHE) {
> 	char sbuf[64], dbuf[64];
> 	struct sockaddr_in6 src, grp;
> 	fprintf(stderr, "(%s,%s)\n",
> 		inet_ntop(AF_INET6, &upcall->im6_src, sbuf, sizeof(sbuf)),
> 		inet_ntop(AF_INET6, &upcall->im6_dst, dbuf, sizeof(dbuf)));	
> 
> 	bzero(&src, sizeof(src));
> 	bzero(&grp, sizeof(grp));
> 
> 	src.sin6_addr = upcall->im6_src;
> 	grp.sin6_addr = upcall->im6_dst;
> 
> 	mrt6_add_mfc(src, grp);
>       }
>     }
> 
>   }
>   if (mrt6_done() < 0)
>     exit(1);
> 
>   exit(0);
> }
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: IPv6 multicast forwarding
  2008-10-24  9:10 ` Alejandro Riveira Fernández
@ 2008-10-24 10:12   ` Pekka Savola
  2008-10-24 13:06     ` Todd Hayton
  0 siblings, 1 reply; 6+ messages in thread
From: Pekka Savola @ 2008-10-24 10:12 UTC (permalink / raw)
  To: Alejandro Riveira Fernández; +Cc: Todd Hayton, linux-kernel, netdev

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1070 bytes --]

On Fri, 24 Oct 2008, Alejandro Riveira Fernández wrote:
>> Let me apologize in advance for the length of this message - it is long!
>>
>> I'm trying to test out IPv6 multicast forwarding on a 2.6.26 kernel
>> and I'm getting some strange values for the upcall messages from the
>> kernel. My code is below, but to give an overview, my setup is as
>> follows:
>>
>>     sender ------ ff15::1 -----> [eth1] linux 2.6.26 [eth0] ------> ...

Maybe this isn't the bug you're looking for but you shouldn't be using 
ff1x multicast addresses in a test like this; ff1x means that the 
multicast group is of "interface-local scope" and it isn't useful for 
multicast forwarding.  So the kernel might be correct in not 
installing multicast forwarding state for a group address like this 
(but if it's a conscious decision, maybe the failure mode should be 
better).  See S 2.7 of RFC4291.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: IPv6 multicast forwarding
  2008-10-24 10:12   ` Pekka Savola
@ 2008-10-24 13:06     ` Todd Hayton
  2008-10-26 10:26       ` Pekka Savola
  0 siblings, 1 reply; 6+ messages in thread
From: Todd Hayton @ 2008-10-24 13:06 UTC (permalink / raw)
  To: Pekka Savola; +Cc: Alejandro Riveira Fernández, linux-kernel, netdev

On Fri, Oct 24, 2008 at 6:12 AM, Pekka Savola <pekkas@netcore.fi> wrote:
> On Fri, 24 Oct 2008, Alejandro Riveira Fernández wrote:
>>>
>>> Let me apologize in advance for the length of this message - it is long!
>>>
>>> I'm trying to test out IPv6 multicast forwarding on a 2.6.26 kernel
>>> and I'm getting some strange values for the upcall messages from the
>>> kernel. My code is below, but to give an overview, my setup is as
>>> follows:
>>>
>>>    sender ------ ff15::1 -----> [eth1] linux 2.6.26 [eth0] ------> ...
>
> Maybe this isn't the bug you're looking for but you shouldn't be using ff1x
> multicast addresses in a test like this; ff1x means that the multicast group
> is of "interface-local scope" and it isn't useful for multicast forwarding.
>  So the kernel might be correct in not installing multicast forwarding state
> for a group address like this (but if it's a conscious decision, maybe the
> failure mode should be better).  See S 2.7 of RFC4291.
>

Hey there, thanks for the response! I may be misinterpreting the RFC
but I thought ff15::1 was a site-local address. As in I break down
ff15::1 as follows -

0xff : identifies the address as multicast
0x15 : 4-bits flags and 4-bits scope where
  flags = 0x1 meaning that the T bit is set as this address is not a
permanently assigned address
  scope = 0x5 indicating site-local scope

Todd H


> --
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: IPv6 multicast forwarding
  2008-10-24 13:06     ` Todd Hayton
@ 2008-10-26 10:26       ` Pekka Savola
  0 siblings, 0 replies; 6+ messages in thread
From: Pekka Savola @ 2008-10-26 10:26 UTC (permalink / raw)
  To: Todd Hayton; +Cc: Alejandro Riveira Fernández, linux-kernel, netdev

On Fri, 24 Oct 2008, Todd Hayton wrote:
> Hey there, thanks for the response! I may be misinterpreting the RFC
> but I thought ff15::1 was a site-local address. As in I break down
> ff15::1 as follows -
>
> 0xff : identifies the address as multicast
> 0x15 : 4-bits flags and 4-bits scope where
>  flags = 0x1 meaning that the T bit is set as this address is not a
> permanently assigned address
>  scope = 0x5 indicating site-local scope

You're right.  The nibbles got switched in my head.  Sorry for that.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* ipv6 multicast forwarding
@ 2003-07-25 12:04 Youngmin Kim
  0 siblings, 0 replies; 6+ messages in thread
From: Youngmin Kim @ 2003-07-25 12:04 UTC (permalink / raw)
  To: Linux Kernel


I have a concern with ipv6 multicast!! But I don't know "linux
forwarding" well

I inserted 2 lines in ip6_mc_input()

	....
	if (ipv6_chk_mcast_addr(skb->dev, &hdr->daddr))
		deliver =1;

	>>if (ipv6_devconf.forwarding == 1)
	>>	ip6_mc_forward(skb, deliver);

	if (deliver)
		discard = 0;
		ip6_input(skb);
	}
	......

I made ip6_mc_forward() which was modified from ip6_forward().

But it doesn't work...
How do I make ip6_mc_forward()? 

I want simple ipv6 multicast forward... 
  When host receive multicast packet, host forward it without multicast
routing cache..
  Then I will filter unneeded packets.

Nobody help me??
Thank you!!


^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2008-10-26 10:26 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-10-23 22:11 IPv6 multicast forwarding Todd Hayton
2008-10-24  9:10 ` Alejandro Riveira Fernández
2008-10-24 10:12   ` Pekka Savola
2008-10-24 13:06     ` Todd Hayton
2008-10-26 10:26       ` Pekka Savola
  -- strict thread matches above, loose matches on Subject: below --
2003-07-25 12:04 ipv6 " Youngmin Kim

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).