On Tue, Jun 25, 2019 at 4:07 AM Jamal Hadi Salim <j...@mojatatu.com> wrote: > > On 2019-06-24 11:26 p.m., Joe Stringer wrote: > [..] > > > > I haven't got as far as UDP yet, but I didn't see any need for a > > dependency on netfilter. > > I'd be curious to see what you did. My experience, even for TCP is > the socket(transparent/tproxy) lookup code (to set skb->sk either > listening or established) is entangled in > CONFIG_NETFILTER_SOMETHING_OR_OTHER. You have to rip it out of > there (in the tproxy tc action into that code). Only then can you > compile out netfilter. > I didnt bother to rip out code for udp case. > i.e if you needed udp to work with the tc action, > youd have to turn on NF. But that was because we had > no need for udp transparent proxying. > IOW: > There is really no reason, afaik, for tproxy code to only be > accessed if netfilter is compiled in. Not sure i made sense.
Oh, I see. Between the existing bpf_skc_lookup_tcp() and bpf_sk_lookup_tcp() helpers in BPF, plus a new bpf_sk_assign() helper and a little bit of lookup code using the appropriate tproxy ports etc. from the BPF side, I was able to get it working. One could imagine perhaps wrapping all this logic up in a higher level "bpf_sk_lookup_tproxy()" helper call or similar, but I didn't go that direction given that the BPF socket primitives seemed to provide the necessary functionality in a more generic manner.
