Hi Florin, I've rebase my changes to your TCP split patch and it kind of works. The problem that I've encountered now is that TCP always hands the buffers to ip[46]_lookup.
Would it be acceptable to modify the application, session and tcp logic to be able to inject a function per application that allows to overwrite the next node lookup in tcp_enqueue_to_ip_lookup_i and tcp_flush_frames_to_output? Thanks Andreas Am Fr., 20. März 2020 um 22:05 Uhr schrieb Florin Coras < [email protected]>: > Hi Andreas, > > I just posted some comments on the patch. I think you can further reduce > the amount of code you need to copy from tcp/session layer. > > Regards, > Florin > > On Mar 20, 2020, at 5:00 AM, Andreas Schultz < > [email protected]> wrote: > > 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 < > [email protected]>: > >> 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 < >> [email protected]> 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 < >> [email protected]>: >> >>> 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 < >>> [email protected]> 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 < >>> [email protected]>: >>> >>>> 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 < >>>> [email protected]> 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: [email protected] >>>> 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: [email protected] >>> 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: [email protected] >> 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: [email protected] > 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: [email protected] 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 (#15872): https://lists.fd.io/g/vpp-dev/message/15872 Mute This Topic: https://lists.fd.io/mt/72004409/21656 Group Owner: [email protected] Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
