Hi Florin, That patch has helped a bit, but now I'm stuck with session_stream_accept.
Creating an application session without having a listener is quick complex. So far I'm resorting to creating a dummy listener, but I would be cleaner not to use that. I have tried to create a session without a listener, but it turns out that there are too many dependencies in the app worker and segment manager handling. Regards Andreas Am Di., 17. März 2020 um 20:15 Uhr schrieb Florin Coras < fcoras.li...@gmail.com>: > Hi Andreas, > > Is this [1] enough for now? I'll eventually do some additional tcp > refactor to make sure we have a generic set of functions that are available > for use cases when only parts of tcp are re-used. > > Regards, > Florin > > [1] https://gerrit.fd.io/r/c/vpp/+/25961 > > On Mar 17, 2020, at 4:20 AM, Andreas Schultz < > andreas.schu...@travelping.com> wrote: > > Hi Florin, > > I had a look at how tcp_connection_alloc is used and it looks to me like I > would need to replicate almost all of tcp46_listen_inline to actually get > the TCP connection setup correctly. I was hoping that I could reuse more of > the existing code. > > Would you be ok with moving much of the body of tcp46_listen_inline into a > header file, marking it always inline? That way I could reuse it without > having to sync changes back all the time. > > Andreas > > Am Mo., 16. März 2020 um 19:09 Uhr schrieb Florin Coras < > fcoras.li...@gmail.com>: > >> 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 >> >> -- >> >> 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 >> w: https://www.travelping.com/ >> Company registration: Amtsgericht Stendal >> Geschaeftsfuehrer: Holger Winkelmann >> Reg. No.: HRB 10578 >> VAT ID: DE236673780 >> >> >> >> > > -- > > 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 > w: https://www.travelping.com/ > Company registration: Amtsgericht Stendal > Geschaeftsfuehrer: Holger Winkelmann > Reg. No.: HRB 10578 > VAT ID: DE236673780 > > > -- 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 w: 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 (#15817): https://lists.fd.io/g/vpp-dev/message/15817 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] -=-=-=-=-=-=-=-=-=-=-=-
