Hi Andreas, >From the info lower, I guess that you want to build a transparent tcp >terminator/proxy. For that, you’ll be forced to do a) because ip-local path is >purely for consuming packets whose destination is local ip addresses. >Moreover, you’ll have to properly classify/match all packets to connections >and hand them to tcp-input (or better yet tcp-input-nolookup) for tcp >processing.
Regarding the passing of data, is that at connection establishment or throughout the lifetime of the connection? If the former, your classifier together with your builtin app will have to instantiate tcp connections and sessions “manually” and properly initialize them whenever it detects a new flow. APIs like session_alloc and tcp_connection_alloc are already exposed. Regards, Florin > On Mar 16, 2020, at 10:39 AM, Andreas Schultz > <andreas.schu...@travelping.com> wrote: > > Hi, > > In our UPF plugin [1], I need to terminate a TCP connection with a non-local > destination IP *and* pass metadata from the plugin into the session. > > I have solve this for the moment with some very ugly hacks. Florin Coras has > rightly criticise those hacks in earlier version of the plugin, but I have > not found a clean solution, yet. > > The UPF plugin is basically a per session mini router instance (that wasn't > my idea, that is the way the specifications are written). It detects a TCP > connection that it needs to handle with rules that are unique for a given > session and then has to apply rules that are also unique per session to that > TCP connection. For the moment only HTTP with redirect rules are handled > (your normal captive portal use case). > > What I need to do is: > a) detect the UPF session and the TCP connection in a packet forwarding > graph node and create a TCP session from it. The destination IP will not be > local, so the normal local input does not work. > b) pass metadata (the matched session and rule) into the TCP connection. > > a) is somewhat doable, but passing metadata from the detection node into the > session proves challenging (without reimplementing all of the TCP input > node). There are no fields (except for IP headers) that are passed from the > vnet buffer into the TCP connection. > > Any hints or ideas? > > Regards, > Andreas > > > [1]: https://gerrit.fd.io/r/c/vpp/+/15798 > <https://gerrit.fd.io/r/c/vpp/+/15798> > > -- > Andreas Schultz > > -- > > Principal Engineer > > t: +49 391 819099-224 > > > ------------------------------- enabling your networks > ----------------------------- > > Travelping GmbH > Roentgenstraße 13 > 39108 Magdeburg > Germany > > > t: +49 391 819099-0 > f: +49 391 819099-299 > > e: i...@travelping.com <mailto:i...@travelping.com> > w: https://www.travelping.com/ <https://www.travelping.com/> > Company registration: Amtsgericht Stendal > Geschaeftsfuehrer: Holger Winkelmann > Reg. No.: HRB 10578 > VAT ID: DE236673780 >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#15794): https://lists.fd.io/g/vpp-dev/message/15794 Mute This Topic: https://lists.fd.io/mt/72004409/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
