From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755342AbYJXJLN (ORCPT ); Fri, 24 Oct 2008 05:11:13 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753649AbYJXJKx (ORCPT ); Fri, 24 Oct 2008 05:10:53 -0400 Received: from nf-out-0910.google.com ([64.233.182.190]:62372 "EHLO nf-out-0910.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753358AbYJXJKu convert rfc822-to-8bit (ORCPT ); Fri, 24 Oct 2008 05:10:50 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type:content-transfer-encoding; b=BcPTrW2lgq2sf+WRsdBmqfRkvxokp0olGcqVijpGFogQw/50Nr4tIwB+AGBPoM9bDF BoWdadyDut2eynovzWjDjHkj12acD01mAmiRRIXI8RaOL3qlkJh95lHFvFsFPaTceFKV Ay4ybPjVvBG32vcpQHX4yP88iSjMin61hq2Do= Date: Fri, 24 Oct 2008 11:10:44 +0200 From: Alejandro Riveira =?UTF-8?B?RmVybsOhbmRleg==?= To: "Todd Hayton" Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org Subject: Re: IPv6 multicast forwarding Message-ID: <20081024111044.74c15155@varda> In-Reply-To: <50a66e370810231511m10a10ca2oa870e9fbd55f4b0e@mail.gmail.com> References: <50a66e370810231511m10a10ca2oa870e9fbd55f4b0e@mail.gmail.com> X-Mailer: Claws Mail 3.5.0 (GTK+ 2.12.9; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org El Thu, 23 Oct 2008 18:11:50 -0400 "Todd Hayton" 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 > #include > #include > #include > > #include > #include > #include > #include > #include > > #include > > #include > #include > #include > #include > > #include > > #include > > #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/