Am Mi., 25. März 2020 um 18:57 Uhr schrieb Florin Coras < 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> 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>: > >> 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 >> 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 >> >> >> > > -- > > 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 (#15960): https://lists.fd.io/g/vpp-dev/message/15960 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] -=-=-=-=-=-=-=-=-=-=-=-
