From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bifrost.lang.hm (lang.hm [66.167.227.134]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id C77673B25D; Sun, 3 Jul 2016 02:16:49 -0400 (EDT) Received: from asgard.lang.hm (asgard.lang.hm [10.0.0.100]) by bifrost.lang.hm (8.13.4/8.13.4/Debian-3) with ESMTP id u636GlNg015218; Sat, 2 Jul 2016 23:16:47 -0700 Date: Sat, 2 Jul 2016 23:16:47 -0700 (PDT) From: David Lang X-X-Sender: dlang@asgard.lang.hm To: =?ISO-8859-15?Q?Dave_T=E4ht?= cc: cake@lists.bufferbloat.net, cerowrt-devel@lists.bufferbloat.net In-Reply-To: Message-ID: References: <57501404.5010704@darbyshire-bryant.me.uk> <6A7C70EE-906E-4624-A84A-645ED4530A07@gmail.com> <5774E766.2050302@darbyshire-bryant.me.uk> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="680960-1754506729-1467526607=:18304" Subject: Re: [Cerowrt-devel] [Cake] conntrack and ipv6 X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2016 06:16:50 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --680960-1754506729-1467526607=:18304 Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT On Sat, 2 Jul 2016, Dave Täht wrote: > It is generally my hope that ipv6 nat will not be widely deployed. > > Firewalls will be stateful instead, and thus there would be no need to > access the conntrack information for ipv6 in cake. well, conntrack is the way that the firewall handles it's state. Conntrack also has features to let you sync it's state from one system to it's backup so that failover maintains the state. > I'm not sure, however, to > what extent ipv6 conntrack is in openwrt today, certainly udp and tcp, > "in" is essentially blocked by default, and needs to be triggered by an > outgoing message. It's compiled into the kernel and on by default (I fight to turn it off for Scale where I don't need to maintain state in the APs as they don't do any firewalling) David Lang > Similarly I'm unfamiliar with the state of ipv6 upnp > and pcp support in openwrt or client applications at present. > > > On 6/30/16 10:33 AM, Kevin Darbyshire-Bryant wrote: >> >> >> On 02/06/16 13:29, Jonathan Morton wrote: >>>> On 2 Jun, 2016, at 14:09, Kevin Darbyshire-Bryant >>>> wrote: >>>> >>>> Cake uses the flow dissector API to do flow hashing...including per >>>> host flows for dual/triple isolation. The unfortunate bit is that >>>> the qdisc inevitably gets placed after packets have been NATed on >>>> egress and before they've been de-NATed on ingress. >>>> >>>> When mentioned before Johnathan said "flow dissector ideally needs to >>>> be tweaked to do this" or words to that effect. >>>> >>>> I'd like to progress that idea...the thought of me kernel programming >>>> should horrify everyone but really I'm asking for help in being >>>> pointed in the right direction to ask for help...and go from there :-) >>> I believe Linux does NAT using a “connection tracker” subsystem. That >>> would contain the necessary data for resolving NAT equivalents. I >>> don’t know how easy it is to query in a qdisc context, though. >> Imagine my joy of discovering http://fatooh.org/esfq-2.6/ - someone has >> already bl**dy done it....and I found it lurking in LEDE as part of a >> patch. >> >> So there relevant bits are something of the order: >> >> >> +#ifdef CONFIG_NET_SCH_ESFQ_NFCT >> + enum ip_conntrack_info ctinfo; >> + struct nf_conn *ct = nf_ct_get(skb, &ctinfo); >> +#endif >> >> +#ifdef CONFIG_NET_SCH_ESFQ_NFCT >> + /* defaults if there is no conntrack info */ >> + info.ctorigsrc = info.src; >> + info.ctorigdst = info.dst; >> + info.ctreplsrc = info.dst; >> + info.ctrepldst = info.src; >> + /* collect conntrack info */ >> + if (ct && ct != &nf_conntrack_untracked) { >> + if (skb->protocol == __constant_htons(ETH_P_IP)) { >> + info.ctorigsrc = >> ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple.src.u3.ip; >> + info.ctorigdst = >> ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple.dst.u3.ip; >> + info.ctreplsrc = >> ct->tuplehash[IP_CT_DIR_REPLY].tuple.src.u3.ip; >> + info.ctrepldst = >> ct->tuplehash[IP_CT_DIR_REPLY].tuple.dst.u3.ip; >> + } >> + else if (skb->protocol == __constant_htons(ETH_P_IPV6)) { >> + /* Again, hash ipv6 addresses into a single u32. */ >> + info.ctorigsrc = >> jhash2(ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple.src.u3.ip6, 4, >> q->perturbation); >> + info.ctorigdst = >> jhash2(ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple.dst.u3.ip6, 4, >> q->perturbation); >> + info.ctreplsrc = >> jhash2(ct->tuplehash[IP_CT_DIR_REPLY].tuple.src.u3.ip6, 4, >> q->perturbation); >> + info.ctrepldst = >> jhash2(ct->tuplehash[IP_CT_DIR_REPLY].tuple.dst.u3.ip6, 4, >> q->perturbation); >> + } >> + >> + } >> +#endif >> >> I'd rip out the IPv6 conntrack stuff as I'm much more concerned by >> handling IPv4 NAT. And I'm not sure how to get it into cake's host >> handling yet but.... >> >> I can feel an experiment and hackery coming on later today :-) >> >> Am overjoyed! >> _______________________________________________ >> Cake mailing list >> Cake@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/cake > _______________________________________________ > Cake mailing list > Cake@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cake --680960-1754506729-1467526607=:18304--