[Cake] flow dissector idea/enhancement - help

[Cake] flow dissector idea/enhancement - help

[Kevin Darbyshire-Bryant]

Hi All,

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 :-)

Kevin

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

[Jonathan Morton]

> On 2 Jun, 2016, at 14:09, Kevin Darbyshire-Bryant <kevin@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.

 - Jonathan Morton

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

[Kevin Darbyshire-Bryant]

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

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

[Jonathan Morton]

> 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.

 - Jonathan Morton

Re: [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@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

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

[Kevin Darbyshire-Bryant]

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

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

[Kevin Darbyshire-Bryant]

On 01/07/16 09:11, Kevin Darbyshire-Bryant wrote:
>
>
>> 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

If I'm honest I'm getting a little despondent.  Coding right at the 
limit of your understand of C and the kernel and everything else is 
really, really tiring and hard.

I discovered net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c has static int
getorigdst(struct sock *sk, int optval, void __user *user, int *len)  
The comment above it is

/* Fast function for those who don't want to parse /proc (and I don't
    blame them). */
/* Reversing the socket's dst/src point of view gives us the reply
    mapping. */

Those interested to see how bad my C really is can 
https://github.com/kdarbyshirebryant/sch_cake/tree/demasq

Maybe those who know what they're doing can offer some assistance.

Cheers,

Kevin

> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake

[Cake] conntrack and ipv6

[Dave Täht]

It is generally my hope that ipv6 nat will not be widely deployed.

Firewalls will be stateful instead, and thus there would be no need to
access the conntrack information for ipv6 in cake.

I'm not sure, however, to
what extent ipv6 conntrack is in openwrt today, certainly udp and tcp,
"in" is essentially blocked by default, and needs to be triggered by an
outgoing message. Similarly I'm unfamiliar with the state of ipv6 upnp
and pcp support in openwrt or client applications at present.


On 6/30/16 10:33 AM, Kevin Darbyshire-Bryant wrote:
> 
> 
> On 02/06/16 13:29, Jonathan Morton wrote:
>>> On 2 Jun, 2016, at 14:09, Kevin Darbyshire-Bryant
>>> <kevin@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!
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake

Re: [Cake] conntrack and ipv6

[moeller0]

Hi Dave,


> On Jul 2, 2016, at 14:47 , Dave Täht <dave@taht.net> wrote:
> 
> It is generally my hope that ipv6 nat will not be widely deployed.
> 
> Firewalls will be stateful instead, and thus there would be no need to
> access the conntrack information for ipv6 in cake.

	I would hope that IPv6 NAT would not re-map ports but instead simply “hide” stuff behind the prefix, so internal hosts would still be differentiated by the remaining 64bits (since individual hosts are supposed to use multiple IPv6 addresses I would be amazed if IPv6NAT would hide behind a /128…). The bigger fairness issue is that individual host can use basically as many IPs as they want and per-IP fairness will not be the right thing anymore anf then all we can use is per-MAC, so no internal routers permitted anymore…

> 
> I'm not sure, however, to
> what extent ipv6 conntrack is in openwrt today, certainly udp and tcp,
> "in" is essentially blocked by default, and needs to be triggered by an
> outgoing message. Similarly I'm unfamiliar with the state of ipv6 upnp
> and pcp support in openwrt or client applications at present.
> 
> 
> On 6/30/16 10:33 AM, Kevin Darbyshire-Bryant wrote:
>> 
>> 
>> On 02/06/16 13:29, Jonathan Morton wrote:
>>>> On 2 Jun, 2016, at 14:09, Kevin Darbyshire-Bryant
>>>> <kevin@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!
>> _______________________________________________
>> Cake mailing list
>> Cake@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cake
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake

Re: [Cake] conntrack and ipv6

[David Lang]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 4451 bytes --]

On Sat, 2 Jul 2016, Dave Täht wrote:

> It is generally my hope that ipv6 nat will not be widely deployed.
>
> Firewalls will be stateful instead, and thus there would be no need to
> access the conntrack information for ipv6 in cake.

well, conntrack is the way that the firewall handles it's state. Conntrack also 
has features to let you sync it's state from one system to it's backup so that 
failover maintains the state.

> I'm not sure, however, to
> what extent ipv6 conntrack is in openwrt today, certainly udp and tcp,
> "in" is essentially blocked by default, and needs to be triggered by an
> outgoing message.

It's compiled into the kernel and on by default (I fight to turn it off for 
Scale where I don't need to maintain state in the APs as they don't do any 
firewalling)

David Lang

> Similarly I'm unfamiliar with the state of ipv6 upnp
> and pcp support in openwrt or client applications at present.
>
>
> On 6/30/16 10:33 AM, Kevin Darbyshire-Bryant wrote:
>> 
>> 
>> On 02/06/16 13:29, Jonathan Morton wrote:
>>>> On 2 Jun, 2016, at 14:09, Kevin Darbyshire-Bryant
>>>> <kevin@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!
>> _______________________________________________
>> Cake mailing list
>> Cake@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cake
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake

Re: [Cake] conntrack and ipv6

[Jonathan Morton]

> On 3 Jul, 2016, at 09:16, David Lang <david@lang.hm> wrote:
> 
>> It is generally my hope that ipv6 nat will not be widely deployed.
>> 
>> Firewalls will be stateful instead, and thus there would be no need to
>> access the conntrack information for ipv6 in cake.
> 
> well, conntrack is the way that the firewall handles it's state. Conntrack also has features to let you sync it's state from one system to it's backup so that failover maintains the state.

Yes, but the point is that in a stateful firewall (as opposed to NAT) no changes to IP addresses occur while traversing the router.  Cake can therefore see the correct addresses without probing conntrack data.

There's still a huge number of people on IPv4 NAT though.

 - Jonathan Morton

Re: [Cake] [Cerowrt-devel] conntrack and ipv6

[moeller0]

Hi Dave,


> On Jul 2, 2016, at 14:47 , Dave Täht <dave@taht.net> wrote:
> 
> It is generally my hope that ipv6 nat will not be widely deployed.

	I checked a few RFCs and both NAT66 (https://tools.ietf.org/html/draft-mrw-behave-nat66-02) or NPTv6 (https://tools.ietf.org/html/rfc6296) only seem to change the prefix-part while maintaining the last 64 bit of IPv6 addresses so that cake will see different (somewhat) stable IPv6 addresses (probably just as stable as IPv6 privacy addresses can be), so internal-IP fairness should not require conntrack at all. They also thankfully leave the port numbers alone, maening that neither udp nor tcp headers typically need to be touched, nice…
        Now, if someone should come up with NATv6/128 that hides all internal addresses behind a single /128 and does the old port remapping song and dance, I believe that person should be entitled to keep all the pieces…


> 
> Firewalls will be stateful instead, and thus there would be no need to
> access the conntrack information for ipv6 in cake.
> 
> I'm not sure, however, to
> what extent ipv6 conntrack is in openwrt today, certainly udp and tcp,
> "in" is essentially blocked by default, and needs to be triggered by an
> outgoing message. Similarly I'm unfamiliar with the state of ipv6 upnp
> and pcp support in openwrt or client applications at present.
> 
> 
> On 6/30/16 10:33 AM, Kevin Darbyshire-Bryant wrote:
>> 
>> 
>> On 02/06/16 13:29, Jonathan Morton wrote:
>>>> On 2 Jun, 2016, at 14:09, Kevin Darbyshire-Bryant
>>>> <kevin@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!
>> _______________________________________________
>> Cake mailing list
>> Cake@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cake
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel