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
[email protected]
https://lists.bufferbloat.net/listinfo/cake
_______________________________________________
Cake mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/cake
