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 <andreas.schu...@travelping.com> > 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 > <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 <mailto: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 >> <mailto: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 > > > > -- > 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 (#15828): https://lists.fd.io/g/vpp-dev/message/15828 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] -=-=-=-=-=-=-=-=-=-=-=-
