Hi Ivan, You’re right that the assert wrongly assumes the connection must’ve been established. I’m guessing you’re only sporadically hitting it because typically the peer should not retransmit the syn after our reset (but probably the packet is lost). Want to push a patch to remove it or should I do it?
Regards, Florin > On Jan 15, 2021, at 3:57 PM, Ivan Shvedunov <ivan...@gmail.com> wrote: > > Hi, > in our UPG project[1] I'm sometimes hitting the following assertion in > tcp[46]-syn-sent when trying to use at least 1 worker thread: > https://github.com/FDio/vpp/blob/35ef865678d82b5a6fd3936716de8afb2fd49e60/src/vnet/tcp/tcp_input.c#L1820-L1821 > > <https://github.com/FDio/vpp/blob/35ef865678d82b5a6fd3936716de8afb2fd49e60/src/vnet/tcp/tcp_input.c#L1820-L1821> > We're using the host stack in a rather non-standard way, so chances are that > this assertion is valid, but so far I didn't manage to understand why. > Problem is that half-open connection cleanup may happen after an unsuccessful > connect notify callback: > https://github.com/FDio/vpp/blob/35ef865678d82b5a6fd3936716de8afb2fd49e60/src/vnet/tcp/tcp_input.c#L1955-L1962 > > <https://github.com/FDio/vpp/blob/35ef865678d82b5a6fd3936716de8afb2fd49e60/src/vnet/tcp/tcp_input.c#L1955-L1962> > https://github.com/FDio/vpp/blob/35ef865678d82b5a6fd3936716de8afb2fd49e60/src/vnet/tcp/tcp_input.c#L1978-L1986 > > <https://github.com/FDio/vpp/blob/35ef865678d82b5a6fd3936716de8afb2fd49e60/src/vnet/tcp/tcp_input.c#L1978-L1986> > which leads us here: > https://github.com/FDio/vpp/blob/35ef865678d82b5a6fd3936716de8afb2fd49e60/src/vnet/tcp/tcp_input.c#L2016-L2021 > > <https://github.com/FDio/vpp/blob/35ef865678d82b5a6fd3936716de8afb2fd49e60/src/vnet/tcp/tcp_input.c#L2016-L2021> > In this case, if the half-open connection belongs to another thread (and it > usually belongs to the main thread), the actual cleanup is delayed and > TCP_CONN_HALF_OPEN_DONE flag is set for the connection, but, due to the > notify call failure, the connection establishment is not completed so the > assertion mentioned above can't be satisfied. > Am I missing a reason why the buffer should actually never reach > tcp[46]-syn-sent node after the corresponding half-open connection is > undergoing this delayed cleanup, so perhaps UPG TCP proxy code needs to be > corrected there, or is this ASSERT indeed invalid? > > [1] https://github.com/travelping/upg-vpp > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#18521): https://lists.fd.io/g/vpp-dev/message/18521 Mute This Topic: https://lists.fd.io/mt/79717445/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
