Hi Florin, I managed to get it working. I still have to copy more code from tcp_input and session_stream_accept that I like, but it works.
Could you have a look at https://gerrit.fd.io/r/c/vpp/+/15798/9/src/plugins/upf/upf_process.c#90 and let me know what you think? Regards Andreas Am Do., 19. März 2020 um 16:18 Uhr schrieb Florin Coras < fcoras.li...@gmail.com>: > 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>: > >> 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 > > > -- 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 (#15825): https://lists.fd.io/g/vpp-dev/message/15825 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] -=-=-=-=-=-=-=-=-=-=-=-
