Hi Zhang,
Thanks for confirming! Give me a few more days to check if there’s any other
improvements to be made in that area.
Regards,
Florin
> On Mar 23, 2023, at 12:00 AM, Zhang Dongya wrote:
>
> Hi,
>
> The new patch works as expected, no assert triggered abort anymore.
>
> Really
Hi,
The new patch works as expected, no assert triggered abort anymore.
Really appreciate your help and thanks a lot.
Florin Coras 于2023年3月22日周三 11:54写道：
> Hi Zhang,
>
> Awesome! Thanks!
>
> Regards,
> Florin
>
> On Mar 21, 2023, at 7:41 PM, Zhang Dongya
> wrote:
>
> Hi Florin,
>
> Thanks a
Hi Zhang,
Awesome! Thanks!
Regards,
Florin
> On Mar 21, 2023, at 7:41 PM, Zhang Dongya wrote:
>
> Hi Florin,
>
> Thanks a lot, the previous patch and with reset disabled have been running 1
> day without issue.
>
> I will enable reset and with your new patch, will provide feedback later.
Hi Florin,
Thanks a lot, the previous patch and with reset disabled have been running
1 day without issue.
I will enable reset and with your new patch, will provide feedback later.
Florin Coras 于2023年3月22日周三 02:12写道：
> Hi,
>
> Okay, resetting of half-opens definitely not supported. I updated
Hi,
Okay, resetting of half-opens definitely not supported. I updated the patch to
just clean them up on forced reset, without sending a reset to make sure
session lookup table cleanup still happens.
Regards,
Florin
> On Mar 20, 2023, at 9:13 PM, Zhang Dongya wrote:
>
> Hi,
>
> After
Hi,
After review my code, I found that I have add a flag to the vnet_disconnect
API which will call session_reset instead of session_close, the reason I do
this is to make intermediate firewall just flush the state and reconstruct
if I later reconnect.
It seems in session_reset logic, for half
Hi,
That last thing is pretty interesting. It’s either the issue fixed by this
patch [1] or sessions are somehow cleaned up multiple times. If it’s the
latter, I’d really like to understand how that happens.
Regards,
Florin
[1] https://gerrit.fd.io/r/c/vpp/+/38507
> On Mar 20, 2023, at
Hi,
After merge this patch and update the test environment, the issue still
persists.
Let me clear my client app config:
1. register a reset callback, which will call vnet_disconnect there and
also trigger reconnect by send event to the ctrl process.)
2. register a connected callback, which will
Hi,
Understood and yes, connect will synchronously fail if port is not available,
so you should be able to retry it later.
Regards,
Florin
> On Mar 20, 2023, at 1:58 AM, Zhang Dongya wrote:
>
> Hi,
>
> It seems the issue occurs when there are disconnect called because our
> network
Hi,
It seems the issue occurs when there are disconnect called because our
network can't guarantee a tcp can't be reset even when 3 ways handshake is
completed (firewall issue :( ).
When we find the app layer timeout, we will first disconnect (because we
record the session handle, this session
Hi,
Inline.
> On Mar 19, 2023, at 6:47 PM, Zhang Dongya wrote:
>
> Hi,
>
> It can be aborted both in established state or half open state because I will
> do timeout in our app layer.
[fc] Okay! Is the issue present irrespective of the state of the session or
does it happen only after a
Hi,
It can be aborted both in established state or half open state because I
will do timeout in our app layer.
Regarding your question,
- Yes we add a builtin in app relys on C apis that mainly use
vnet_connect/disconnect to connect or disconnect session.
- We call these api in a vpp ctrl
Hi,
When you abort the connection, is it fully established or half-open? Half-opens
are cleaned up by the owner thread after a timeout, but the 5-tuple should be
assigned to the fully established session by that point.
tcp_half_open_connection_cleanup does not cleanup the bihash instead
13 matches
Mail list logo
