From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 92DE23B2A0; Sat, 2 Jul 2016 09:00:28 -0400 (EDT) Received: from hms-beagle.lan ([93.237.69.26]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0LfjlS-1bgmJM2rjG-00pQ3U; Sat, 02 Jul 2016 15:00:26 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: moeller0 In-Reply-To: Date: Sat, 2 Jul 2016 15:00:24 +0200 Cc: cake@lists.bufferbloat.net, cerowrt-devel@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: <4BDF756E-5F49-4DB3-8D97-ED6E1B88D126@gmx.de> References: <57501404.5010704@darbyshire-bryant.me.uk> <6A7C70EE-906E-4624-A84A-645ED4530A07@gmail.com> <5774E766.2050302@darbyshire-bryant.me.uk> To: =?utf-8?Q?Dave_T=C3=A4ht?= X-Mailer: Apple Mail (2.2104) X-Provags-ID: V03:K0:wY5FYyNjiqOzojbLxB5EUQIEAcrPQy0YV08giekwP1ELkkmnqdS u+u7w7bLMwmqsFDrGByqKRv2407G+wZJ1BtWs4QRaY0h8VGqwGEXk49/AdFBu3ON9m5DwRG e+sVrN0587MB7LrE+kJXMudxUo2O8pxMD04KDMUgbVsMvoZ0mksfVy8iH3d5UHMcP43N8Zx ZmhQfCGTpw8nialCvUBYA== X-UI-Out-Filterresults: notjunk:1;V01:K0:vDbwrgQu/Kw=:eOgDT6d/rkB5Z2l9xxVLlO 9qZw25DEC/584QWW+pOVdy/yi85s4BELG/WQNCAqWYdKwa3/NbXQk9YZ5egAzF/yyKnfsmRFL 0r2mnePxeVU7mWz0uc7sYG6vmF+zLkRHZGWRw8iYQDWW1Bw+Ie5+I7V8/YF27soFUMOUCVMHH lYYkAjIIMW191qhjMpRTzHjHBIuObY6RBgVz32rX32UcyGsltZlBKS0K8RenYf3ve20o6e+vP uIb662wM6kcZe0j7Sp8nK5/V6aIYlW8OArFg711EH5yB/8DUWew7/ZCcctgE++7I6G+ka3BAQ p2OHFpt4b6t6W7aGsh3Bk/WECUbaDVeQH+w38cwJ6GWUDhU51wyDogoRYqB/S782nL/YmzNZu oJIDgSahg55sF8yKcCDNRVVhyx8T92eegSFLMuSSR9IXA0yT0g57/C05379Lt+Y6/Jb4ofcGO J5zPwfISYnEmVzxd3xEUecz2JOhcyixcEGoVoXOFhhLKCMcKMkIBsqaw3NLJGmJVATNMDcA8D cOlhLOOxigEv1JtaZ1gI39blJPfYJj7DXrZi3XLVLM9FLXHQmBxNiwmNrJDACECgvntY5+VQh fv0qqa4bpmRdtycWMet6j0WfckfG2oPYz6nj0ZEllflkcNJsxWeAWECep1dYwzrsZoVPXRyV8 QUG6OWCDBBg0Tw60f2mPpFpOmniRcgg+mfpUMgjjErQIqb4A8k+n2Spf563/Uer55vQNd4waN 8fkZWDtjEBYqlFTAHdQtDJeCiH/dRkKxfO6cKtG0xaLkoXPUKd2D+w10G1gwKWQQg1OAR9pkr XMWxwBR 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: Sat, 02 Jul 2016 13:00:29 -0000 Hi Dave, > On Jul 2, 2016, at 14:47 , Dave T=C3=A4ht wrote: >=20 > It is generally my hope that ipv6 nat will not be widely deployed. >=20 > Firewalls will be stateful instead, and thus there would be no need to > access the conntrack information for ipv6 in cake. I would hope that IPv6 NAT would not re-map ports but instead = simply =E2=80=9Chide=E2=80=9D stuff behind the prefix, so internal hosts = would still be differentiated by the remaining 64bits (since individual = hosts are supposed to use multiple IPv6 addresses I would be amazed if = IPv6NAT would hide behind a /128=E2=80=A6). The bigger fairness issue is = that individual host can use basically as many IPs as they want and = per-IP fairness will not be the right thing anymore anf then all we can = use is per-MAC, so no internal routers permitted anymore=E2=80=A6 >=20 > 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. Similarly I'm unfamiliar with the state of ipv6 upnp > and pcp support in openwrt or client applications at present. >=20 >=20 > On 6/30/16 10:33 AM, Kevin Darbyshire-Bryant wrote: >>=20 >>=20 >> On 02/06/16 13:29, Jonathan Morton wrote: >>>> On 2 Jun, 2016, at 14:09, Kevin Darbyshire-Bryant >>>> wrote: >>>>=20 >>>> 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. >>>>=20 >>>> When mentioned before Johnathan said "flow dissector ideally needs = to >>>> be tweaked to do this" or words to that effect. >>>>=20 >>>> 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 =E2=80=9Cconnection tracker=E2=80=9D = subsystem. That >>> would contain the necessary data for resolving NAT equivalents. I >>> don=E2=80=99t 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. >>=20 >> So there relevant bits are something of the order: >>=20 >>=20 >> +#ifdef CONFIG_NET_SCH_ESFQ_NFCT >> + enum ip_conntrack_info ctinfo; >> + struct nf_conn *ct =3D nf_ct_get(skb, &ctinfo); >> +#endif >>=20 >> +#ifdef CONFIG_NET_SCH_ESFQ_NFCT >> + /* defaults if there is no conntrack info */ >> + info.ctorigsrc =3D info.src; >> + info.ctorigdst =3D info.dst; >> + info.ctreplsrc =3D info.dst; >> + info.ctrepldst =3D info.src; >> + /* collect conntrack info */ >> + if (ct && ct !=3D &nf_conntrack_untracked) { >> + if (skb->protocol =3D=3D __constant_htons(ETH_P_IP)) = { >> + info.ctorigsrc =3D >> ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple.src.u3.ip; >> + info.ctorigdst =3D >> ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple.dst.u3.ip; >> + info.ctreplsrc =3D >> ct->tuplehash[IP_CT_DIR_REPLY].tuple.src.u3.ip; >> + info.ctrepldst =3D >> ct->tuplehash[IP_CT_DIR_REPLY].tuple.dst.u3.ip; >> + } >> + else if (skb->protocol =3D=3D = __constant_htons(ETH_P_IPV6)) { >> + /* Again, hash ipv6 addresses into a single = u32. */ >> + info.ctorigsrc =3D >> jhash2(ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple.src.u3.ip6, 4, >> q->perturbation); >> + info.ctorigdst =3D >> jhash2(ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple.dst.u3.ip6, 4, >> q->perturbation); >> + info.ctreplsrc =3D >> jhash2(ct->tuplehash[IP_CT_DIR_REPLY].tuple.src.u3.ip6, 4, >> q->perturbation); >> + info.ctrepldst =3D >> jhash2(ct->tuplehash[IP_CT_DIR_REPLY].tuple.dst.u3.ip6, 4, >> q->perturbation); >> + } >> + >> + } >> +#endif >>=20 >> 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.... >>=20 >> I can feel an experiment and hackery coming on later today :-) >>=20 >> 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