From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 4537221F32C for ; Wed, 8 Oct 2014 19:48:58 -0700 (PDT) Received: by mail-oi0-f48.google.com with SMTP id g201so856869oib.7 for ; Wed, 08 Oct 2014 19:48:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=ky/oGaT4bo1HFFVl1RrpfRN4YVDeULyAu3Veh4lmOK4=; b=nbnhlWo+NZB1Gq5AA2wm36vatIuV/GGrfjirrHAljbsZ/OVKdxMngeG6WtdrFp2ueq 2PjPuEuMRULa03Ch5VMZFHf36ddCSOWhJLk8yBE6ZaSY6zPr+IKJeXtD1RMkT4JRwTeU yajO1V4OIosrod4R2WOHg0guZRWmvpporB0N1CT0kjbF3V/9F4uMbEJ1blYYyKmiPyLO 0WN87B1cvUdVbV30+rE0qBbNN7dmJldAw5gMO9V//pQGNeFIgqUtOzCPrtFAULr0+Shy F1ORmzmOVZz12YgfGLomBxvn7+qrFHphnuvLHx26e3naie/3V1LEfs/HT43tMBFLJzLz lojA== MIME-Version: 1.0 X-Received: by 10.182.163.114 with SMTP id yh18mr18121563obb.0.1412822937144; Wed, 08 Oct 2014 19:48:57 -0700 (PDT) Received: by 10.202.227.76 with HTTP; Wed, 8 Oct 2014 19:48:57 -0700 (PDT) In-Reply-To: References: Date: Wed, 8 Oct 2014 19:48:57 -0700 Message-ID: From: Dave Taht To: Richard Edmands Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "cerowrt-devel@lists.bufferbloat.net" Subject: Re: [Cerowrt-devel] possible ingress shaping bug? X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 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: Thu, 09 Oct 2014 02:49:27 -0000 On Mon, Oct 6, 2014 at 3:07 AM, Richard Edmands wrote= : > Greetings Everyone! > As part of research into a related part of the kernel we ran across an > oddity with nfct on ifb devices. > To give weight to the existence of the oddity, a Debian Jessie (so 3.16.3 > based kernel) system was setup with wan and lan ports. > A modified version of the gentoo fq_codel script was used (Wan is eth0 an= d > associated IFB is ifb0). Including script. > The kernel had 2 printk's inserted (see included change to cls_flows.c) t= o > print out the ip addresses which were being returned to the flows process > for nfct-src and nfct-dst. > The nfct-src attached to eth0 printk was heard from, it returned the righ= t > answers and some nonsense as expected. > The nfct-dst attached to ifb0 printk didn't return a thing, not even > nonsense. > -------------------------------------------------------------------------= ----------------------------- > (Wild speculation) > Maybe the conntrack lookup only works correctly from the right device? so > the lookup from the packet on ifb0 is being looked up in conntrack as if = it > should relate to a connection on ifb0 instead of a connection on eth0? does straight src or dst work in ifb? The conntrack stuff is long gone by the time you get to ifb. > -------------------------------------------------------------------------= -- > #!/bin/sh > > > > ## Paths and definitions > tc=3D/sbin/tc > IPT=3Diptables > > #The interface name of the internet link > ext=3Deth0 > > #Ignore this > ext_ingress=3Difb0 > > > > # Set these as per your adsl sync rate, at 90% to start with, modify up a= nd > down until the tests work. > ext_up=3D40000kbit > ext_down=3D40000kbit > > > ethtool -K eth0 tso off gro off gso off > ethtool -K eth1 tso off gro off gso off > > modprobe ifb > modprobe sch_fq_codel > modprobe act_mirred > modprobe cls_flow > > # Clear old queuing disciplines (qdisc) on the interfaces > $tc qdisc del dev $ext root > $tc qdisc del dev $ext ingress > $tc qdisc del dev $ext_ingress root > $tc qdisc del dev $ext_ingress ingress > > > > ######### > # INGRESS > ######### > > # Create ingress on external interface > $tc qdisc add dev $ext handle ffff: ingress > ifconfig $ext_ingress up # if the interace is not up bad things happen > > # Forward all ingress traffic to the IFB device > $tc filter add dev $ext parent ffff: protocol all u32 match u32 0 0 actio= n > mirred egress redirect dev $ext_ingress > > # Create an EGRESS filter on the IFB device > #You can play with the r2q value, higher for faster links, lower for slow= er. > FIXME? Totally need some maths and tables for the correct values in vario= us > situations. Is being too high safer than being too low? It is best to be correct. See the sqm source code and recent threads on thi= s list. *I* don't grok all that is involved on getting dsl or PPPoe right, all the systems I have access to are cable or fiber. > $tc qdisc add dev $ext_ingress root handle 1: htb default 12 r2q 5 > > # Add root class HTB with rate limiting > $tc class add dev $ext_ingress parent 1: classid 1:1 htb rate $ext_down > overhead 40 mtu 1492 mpu 53 linklayer atm > $tc class add dev $ext_ingress parent 1:1 classid 1:11 htb rate $ext_down > prio 0 overhead 40 mtu 1492 mpu 53 linklayer atm > $tc class add dev $ext_ingress parent 1:1 classid 1:12 htb rate $ext_down > prio 0 overhead 40 mtu 1492 mpu 53 linklayer atm > > > #This is where fq_codel is installed for downlink traffic > $tc qdisc add dev $ext_ingress parent 1:11 fq_codel noecn target 50ms > interval 300ms quantum 512 flows 1024 limit 3000 > $tc qdisc add dev $ext_ingress parent 1:12 fq_codel noecn target 50ms > interval 300ms quantum 512 flows 1024 limit 3000 > > > #FIXME? Really need to find/have a discussion and determine good values f= or > this > $tc filter add dev $ext_ingress protocol ip parent 1: handle 11 flow hash > keys nfct-dst divisor 1024 baseclass 1:11 > $tc filter add dev $ext_ingress protocol ip parent 1: handle 12 flow hash > keys nfct-dst divisor 1024 baseclass 1:12 dst is the correct thing here. > # Yes I KNOW this does not work. > $tc filter add dev $ext_ingress protocol ip parent 1: prio 2 u32 match ip > dst 172.30.200.2 flowid 1:11 Well, actually no, this should work. Unless the parent should be something = else. > > > ######### > # EGRESS > ######### > > # Add FQ_CODEL to EGRESS on external interface > #You can play with the r2q value, higher for faster links, lower for slow= er. > FIXME? Totally need some maths and tables for the correct values in vario= us > situations. Is being too high safer than being too low? > $tc qdisc add dev $ext root handle 1: htb default 12 r2q 1 > > # Add root class HTB with rate limiting > $tc class add dev $ext parent 1: classid 1:1 htb rate $ext_up overhead 40 > mtu 1492 mpu 53 linklayer atm > $tc class add dev $ext parent 1:1 classid 1:11 htb rate 70kbit ceil $ext_= up > overhead 40 mtu 1492 mpu 53 linklayer atm > $tc class add dev $ext parent 1:1 classid 1:12 htb rate 30kbit ceil $ext_= up > overhead 40 mtu 1492 mpu 53 linklayer atm > > > #This is where fq_codel is installed for uplink traffic > $tc qdisc add dev $ext parent 1:11 handle 11: fq_codel noecn target 100ms > interval 300ms quantum 300 flows 1024 limit 3000 > $tc qdisc add dev $ext parent 1:12 handle 12: fq_codel noecn target 100ms > interval 300ms quantum 300 flows 1024 limit 3000 > > > > > > $tc filter add dev $ext protocol ip parent 1: handle 11 flow hash keys > nfct-src divisor 1024 baseclass 1:11 > $tc filter add dev $ext protocol ip parent 1: handle 12 flow hash keys > nfct-src divisor 1024 baseclass 1:12 > > $tc filter add dev $ext protocol ip parent 1: prio 2 u32 match ip src > 172.30.200.2 flowid 1:11 > -------------------------------------------------------------------------= --------------------------------------------------- > > --- linux-3.16.3.orig/net/sched/cls_flow.c 2014-09-18 03:22:16.000000000 > +1000 > +++ linux-3.16.3/net/sched/cls_flow.c 2014-10-04 13:01:56.000000000 +1000 > @@ -143,6 +143,7 @@ > { > switch (skb->protocol) { > case htons(ETH_P_IP): > +printk(KERN_WARNING "nfct src %d \n", (ntohl(CTTUPLE(skb, src.u3.ip))) )= ; > return ntohl(CTTUPLE(skb, src.u3.ip)); > case htons(ETH_P_IPV6): > return ntohl(CTTUPLE(skb, src.u3.ip6[3])); > @@ -155,6 +156,7 @@ > { > switch (skb->protocol) { > case htons(ETH_P_IP): > +printk(KERN_WARNING "nfct dst %d \n", (ntohl(CTTUPLE(skb, dst.u3.ip))) )= ; > return ntohl(CTTUPLE(skb, dst.u3.ip)); > case htons(ETH_P_IPV6): > return ntohl(CTTUPLE(skb, dst.u3.ip6[3])); > > > _______________________________________________ > Cerowrt-devel mailing list > Cerowrt-devel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel > --=20 Dave T=C3=A4ht https://www.bufferbloat.net/projects/make-wifi-fast