Hi Andreas, 

Understood. Let me know if the next_node_index works for you. 

Regards,
Florin

> On Mar 25, 2020, at 12:39 PM, 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.
> 
> Thanks, I missed that. 
> 
>  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? 
> 
> I don't need it for syns, only for synack. I missed the next_node_index in tc.
>
> 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. 
> 
> The reason for avoiding fib lookups is that I sometimes need to pass IP 
> frames to UEs before I know in which fib the UE will end up. My session logic 
> does know how to encapsulate the packet, but it needs to get the IP packets 
> to the node without going through the fib lookup.
>
> 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 (#15877): https://lists.fd.io/g/vpp-dev/message/15877
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]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to