<div dir="ltr">Greetings Everyone!<div><div>As part of research into a related part of the kernel we ran across an oddity with nfct on ifb devices.</div><div>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. </div><div>A modified version of the gentoo fq_codel script was used (Wan is eth0 and associated IFB is ifb0). Including script.</div><div>The kernel had 2 printk's inserted (see included change to cls_flows.c) to print out the ip addresses which were being returned to the flows process for nfct-src and nfct-dst.</div><div>The nfct-src attached to eth0 printk was heard from, it returned the right answers and some nonsense as expected.</div><div>The nfct-dst attached to ifb0 printk didn't return a thing, not even nonsense.</div><div>------------------------------------------------------------------------------------------------------</div><div>(Wild speculation)</div><div>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?</div><div><br></div><div>---------------------------------------------------------------------------</div><div><div>#!/bin/sh</div><div><br></div><div><br></div><div><br></div><div>## Paths and definitions</div><div>tc=/sbin/tc</div><div>IPT=iptables</div><div><br></div><div>#The interface name of the internet link</div><div>ext=eth0</div><div><br></div><div>#Ignore this</div><div>ext_ingress=ifb0</div><div><br></div><div><br></div><div><br></div><div># Set these as per your adsl sync rate, at 90% to start with, modify up and down until the tests work.</div><div>ext_up=40000kbit</div><div>ext_down=40000kbit</div><div><br></div><div><br></div><div>ethtool -K eth0 tso off gro off gso off</div><div>ethtool -K eth1 tso off gro off gso off</div><div><br></div><div>modprobe ifb</div><div>modprobe sch_fq_codel</div><div>modprobe act_mirred</div><div>modprobe cls_flow</div><div><br></div><div># Clear old queuing disciplines (qdisc) on the interfaces</div><div>$tc qdisc del dev $ext root</div><div>$tc qdisc del dev $ext ingress</div><div>$tc qdisc del dev $ext_ingress root</div><div>$tc qdisc del dev $ext_ingress ingress</div><div><br></div><div><br></div><div><br></div><div>#########</div><div># INGRESS</div><div>#########</div><div><br></div><div># Create ingress on external interface</div><div>$tc qdisc add dev $ext handle ffff: ingress</div><div>ifconfig $ext_ingress up # if the interace is not up bad things happen</div><div><br></div><div># Forward all ingress traffic to the IFB device</div><div>$tc filter add dev $ext parent ffff: protocol all u32 match u32 0 0 action mirred egress redirect dev $ext_ingress</div><div><br></div><div># Create an EGRESS filter on the IFB device</div><div>#You can play with the r2q value, higher for faster links, lower for slower. FIXME? Totally need some maths and tables for the correct values in various situations. Is being too high safer than being too low?</div><div>$tc qdisc add dev $ext_ingress root handle 1: htb default 12 r2q 5</div><div><br></div><div># Add root class HTB with rate limiting</div><div>$tc class add dev $ext_ingress parent 1: classid 1:1 htb rate $ext_down overhead 40 mtu 1492 mpu 53 linklayer atm</div><div>$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</div><div>$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</div><div><br></div><div><br></div><div>#This is where fq_codel is installed for downlink traffic</div><div>$tc qdisc add dev $ext_ingress parent 1:11 fq_codel noecn target 50ms interval 300ms quantum 512 flows 1024 limit 3000<br></div><div>$tc qdisc add dev $ext_ingress parent 1:12 fq_codel noecn target 50ms interval 300ms quantum 512 flows 1024 limit 3000</div><div><br></div><div><br></div><div>#FIXME? Really need to find/have a discussion and determine good values for this<br></div><div>$tc filter add dev $ext_ingress protocol ip parent 1: handle 11 flow hash keys nfct-dst divisor 1024 baseclass 1:11</div><div>$tc filter add dev $ext_ingress protocol ip parent 1: handle 12 flow hash keys nfct-dst divisor 1024 baseclass 1:12</div><div><br></div><div># Yes I KNOW this does not work.</div><div>$tc filter add dev $ext_ingress protocol ip parent 1: prio 2 u32 match ip dst 172.30.200.2 flowid 1:11</div><div><br></div><div><br></div><div>#########</div><div># EGRESS</div><div>#########</div><div><br></div><div># Add FQ_CODEL to EGRESS on external interface</div><div>#You can play with the r2q value, higher for faster links, lower for slower. FIXME? Totally need some maths and tables for the correct values in various situations. Is being too high safer than being too low?</div><div>$tc qdisc add dev $ext root handle 1: htb default 12 r2q 1</div><div><br></div><div># Add root class HTB with rate limiting</div><div>$tc class add dev $ext parent 1: classid 1:1 htb rate $ext_up overhead 40 mtu 1492 mpu 53 linklayer atm<br></div><div>$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</div><div>$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</div><div><br></div><div><br></div><div>#This is where fq_codel is installed for uplink traffic</div><div>$tc qdisc add dev $ext parent 1:11 handle 11: fq_codel noecn target 100ms interval 300ms quantum 300 flows 1024 limit 3000</div><div>$tc qdisc add dev $ext parent 1:12 handle 12: fq_codel noecn target 100ms interval 300ms quantum 300 flows 1024 limit 3000</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div>$tc filter add dev $ext protocol ip parent 1: handle 11 flow hash keys nfct-src divisor 1024 baseclass 1:11</div><div>$tc filter add dev $ext protocol ip parent 1: handle 12 flow hash keys nfct-src divisor 1024 baseclass 1:12</div><div><br></div><div>$tc filter add dev $ext protocol ip parent 1: prio 2 u32 match ip src 172.30.200.2 flowid 1:11</div></div><div>----------------------------------------------------------------------------------------------------------------------------</div><div><br></div><div>--- linux-3.16.3.orig/net/sched/cls_flow.c<span class="" style="white-space:pre">   </span>2014-09-18 03:22:16.000000000 +1000<br></div><div><div>+++ linux-3.16.3/net/sched/cls_flow.c<span class="" style="white-space:pre">      </span>2014-10-04 13:01:56.000000000 +1000</div><div>@@ -143,6 +143,7 @@</div><div> {</div><div> <span class="" style="white-space:pre">  </span>switch (skb->protocol) {</div><div> <span class="" style="white-space:pre">      </span>case htons(ETH_P_IP):</div><div>+printk(KERN_WARNING "nfct src %d \n", (ntohl(CTTUPLE(skb, src.u3.ip))) );</div><div> <span class="" style="white-space:pre">         </span>return ntohl(CTTUPLE(skb, src.u3.ip));</div><div> <span class="" style="white-space:pre">   </span>case htons(ETH_P_IPV6):</div><div> <span class="" style="white-space:pre">          </span>return ntohl(CTTUPLE(skb, src.u3.ip6[3]));</div><div>@@ -155,6 +156,7 @@</div><div> {</div><div> <span class="" style="white-space:pre">   </span>switch (skb->protocol) {</div><div> <span class="" style="white-space:pre">      </span>case htons(ETH_P_IP):</div><div>+printk(KERN_WARNING "nfct dst %d \n", (ntohl(CTTUPLE(skb, dst.u3.ip))) );</div><div> <span class="" style="white-space:pre">         </span>return ntohl(CTTUPLE(skb, dst.u3.ip));</div><div> <span class="" style="white-space:pre">   </span>case htons(ETH_P_IPV6):</div><div> <span class="" style="white-space:pre">          </span>return ntohl(CTTUPLE(skb, dst.u3.ip6[3]));</div></div><div><br></div></div></div>