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. Regards, Florin > On Mar 25, 2020, at 9:51 AM, Andreas Schultz <[email protected]> > 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 > <[email protected] <mailto:[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] >> <mailto:[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 >> <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] <mailto:[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] <mailto:[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] <mailto:[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 >>> <https://gerrit.fd.io/r/c/vpp/+/25961> >>> >>>> On Mar 17, 2020, at 4:20 AM, Andreas Schultz >>>> <[email protected] <mailto:[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] <mailto:[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] <mailto:[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 >>>>> <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] <mailto:[email protected]> >>>>> 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: [email protected] <mailto:[email protected]> >>>> 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: [email protected] <mailto:[email protected]> >>> 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: [email protected] <mailto:[email protected]> >> 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: [email protected] <mailto:[email protected]> > 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 (#15875): https://lists.fd.io/g/vpp-dev/message/15875 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]] -=-=-=-=-=-=-=-=-=-=-=-
