Hi Andreas, Probably the best option, at this time, would be to completely avoid using session lookup and accept infra because you can’t have a generic listener for sessions you intercept. Or you could have a generic 0/0 listener but that would also intercept connections meant for local termination. That’s not to say you can’t use session tables.
Instead, you can manually create sessions in your custom tcp-listen node and 1) do the linking with the tcp connection, i.e., fix the session/connection indices and 2) assign the sessions to your app’s worker and allocate fifos 3) initialize session state in your app either directly or by calling app_worker_accept_notify. Practically this custom node will bootstrap tcp, session layer and app state and after that you can let the sessions “run normally”. You probably also want to mark the transport connection (tcp “base class”) with TRANSPORT_CONNECTION_F_NO_LOOKUP, to avoid session layer attempts to look up the connection in builtin session tables. Regards, Florin > On Mar 19, 2020, at 4:54 AM, Andreas Schultz <andreas.schu...@travelping.com> > wrote: > > 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 <mailto: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 > <https://gerrit.fd.io/r/c/vpp/+/25961> > >> On Mar 17, 2020, at 4:20 AM, Andreas Schultz <andreas.schu...@travelping.com >> <mailto: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 <mailto: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 <mailto: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 >>> >> >> >> >> -- >> 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 > > > > -- > 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 (#15821): https://lists.fd.io/g/vpp-dev/message/15821 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] -=-=-=-=-=-=-=-=-=-=-=-
