[Cake] flow dissector idea/enhancement - help

Kevin Darbyshire-Bryant kevin at darbyshire-bryant.me.uk
Thu Jun 30 05:33:26 EDT 2016



On 02/06/16 13:29, Jonathan Morton wrote:
>> On 2 Jun, 2016, at 14:09, Kevin Darbyshire-Bryant <kevin at darbyshire-bryant.me.uk> 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!


More information about the Cake mailing list