[Cake] flow dissector idea/enhancement - help

[Kevin Darbyshire-Bryant]

On 30/06/16 11:27, Jonathan Morton wrote:
>> On 30 Jun, 2016, at 12:33, Kevin Darbyshire-Bryant <kevin at 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