Re: [Cake] flow dissector idea/enhancement - help

[Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk>]

On 30/06/16 20:23, Kevin Darbyshire-Bryant wrote:
>
>
> On 30/06/16 11:27, Jonathan Morton wrote:
>>> On 30 Jun, 2016, at 12:33, Kevin Darbyshire-Bryant 
>>> <kevin@darbyshire-bryant.me.uk> wrote:
>>>
>>> +#ifdef CONFIG_NET_SCH_ESFQ_NFCT
>>> +       enum ip_conntrack_info ctinfo;
>>> +       struct nf_conn *ct = nf_ct_get(skb, &ctinfo);
>>> +#endif
>> Good find.  If this actually works the way we want it to, it’ll make 
>> all the host-dependent modes (including triple-isolation) much more 
>> useful on the outer side of a NAT.
>>
>> My main concern is that the conntrack state might not be sorted out 
>> until it hits the firewall or routing logic.  I’ll be very pleased if 
>> it happens sooner, or is actually triggered by the query rather than 
>> passing to some specific stage of processing.
>>
>> I have other work to do on the host and flow processing, but I think 
>> that’ll be independent of the hash function, which is where you want 
>> to be looking.
> I knew I shouldn't have got so excited.  It sort of half works-ish. I 
> hacked something together and then added a few printk statements to 
> help with debugging.  For testing I setup 'dual-dst' on the ifb4wan 
> (ingress) interface, and set 'dual-src' on the wan4 (egress) 
> interface.  Testing showed the input side of things hadn't got as far 
> as conntrack association by the time it hit the qdisc.  The output 
> side of things definitely has conntrack associations. They're a bit 
> strange and I need to do a bit more digging to see if there's anything 
> useful here, it might be possible to do per host egress fairness.   
> For reasons I don't understand it looks as though I'm occasionally 
> seeing the 'reply' conntrack association and not just the 
> 'incoming'...in other words I'm seeing 'internet' source addresses, 
> not just internal lan.
>
> I'm beginning to think there's a reason why enhanced sfq which is 
> where I found that code never made it upstream :-/   It's been/being 
> an interesting little diversion...and I've modified a kernel module 
> that so far doesn't crash :-)
>
> KDB
The brain cell awoke with the thought that 'we don't need all the 
conntrack info filled in, all we need is to find the conntrack entry 
matching the src/dst tuple depending on direction.  nf_ct_get(skb, 
&ctinfo) is a function of convenience....we need to do it the 
inconvenient way.  there's gotta be conntrack tuple lookups available 
and we must have enough info for this as the skb is right there.  KDB 
goes digging.

KDB