Hi Andreas, Unfortunately, you got it right. We’d need changes in the whole vnet_connect chain, including the code that generates syns, to support a non-custom next-node for syns.
Half-open connections are allocated out of a different pool, so we can’t reuse tcp-output logic. We could add a custom tcp-output for syns, that knows how to work with syns/half-open connection, and check if they need special treatment, provided the apis are extended to support a custom next node. That’s a lot of machinery and it won’t be reusable for resets without a connection. So, since this is all data/packet driven, you could at least for now, do something similar to what you did with your custom listen node. That is, manually generate syn packets and setup tcp/session layer appropriately. Alternatively, you could have an ip-output feature that intercepts locally generated packets that are syns or rsts. Regards, Florin > On Mar 31, 2020, at 8:59 AM, Andreas Schultz <andreas.schu...@travelping.com> > wrote: > > Am Mi., 25. März 2020 um 18:57 Uhr schrieb Florin Coras > <fcoras.li...@gmail.com <mailto:fcoras.li...@gmail.com>>: > Hi Andreas, > > You have in the tcp connection next_node_index and next_node_opaque which can > be used to determine the next node and some additional info you may want to > send to a custom next node from tcp_output. You can initialize those as you > may see fit in your custom listen node. > > For synacks, we use tcp-output path but for syn we do use a different path > because the connections are not fully established, and I guess this is what > you’re asking about lower. So, just to be sure we’re on the same page, are > you trying to avoid the fib lookup for syn packets? > > If yes, first of all, why (out of curiosity)? Second, this becomes cumbersome > both because of the api changes and because we’d like to avoid polling more > queues of frames (ip_lookup now) in tcp. We might be able to improve what we > have but it’s going to be an involved change. > > I have to revert my previous statement, I do need to handle *all* packets for > a TCP connection, including the SYN and RESETs. > The way the UPF logic is specified means that I have to intercept > (transparent proxy) connections and perform custom actions both on the > incoming and outgoing connection. In some setups I have to apply per session > accounting and/or policy routing on the outgoing connection. This has to > happen in the context of the original session, so using the generic VPP > mechanisms does not work as they are not preserving the session context. > > I've seen your recent change to reuse the session infra for syns and resets. > That seems to use nodes that are global to the whole TCP stack. Messing with > those would probably affect all TCP connections, right? I'm looking for a per > connection mechanism that also applies to SYNS and RESETs. > Any hints? > > Many thanks, > Andreas > > > Regards, > Florin > >> On Mar 25, 2020, at 9:51 AM, Andreas Schultz <andreas.schu...@travelping.com >> <mailto:andreas.schu...@travelping.com>> wrote: >> >> 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 >> <fcoras.li...@gmail.com <mailto:fcoras.li...@gmail.com>>: >> 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 <mailto: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 >> >> >> >> -- >> 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 (#15961): https://lists.fd.io/g/vpp-dev/message/15961 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] -=-=-=-=-=-=-=-=-=-=-=-
