On 30/06/16 11:27, Jonathan Morton wrote:
On 30 Jun, 2016, at 12:33, Kevin Darbyshire-Bryant
<[email protected]> 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
_______________________________________________
Cake mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/cake
