By adding the following code right after process dispatch in the main loop,
the crash is fixed.
So I think the condition mentioned above is a rare but valid case.
A ctrl process node being scheduled adds a packet (pending frame) to a node
and the packet is referring to an interface which will be
Hi Kai,
Thanks for your response. Yes your understanding is correct and
`stat_segment_connect` is called only when querying SAs. This query does not
occur unless: 1) you ask for SA status and 2) before sending DPD messages. I'm
afraid using 5.9.6 version did not change anything. May I ask if in
Hi list,
During the test, when l3sub if is deleted, I got a new abort in interface
drop node, seems the packet reference to a deleted interface.
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
> #1 0x7face8d17859 in __GI_abort () at abort.c:79
> #2 0x004073
Hi Mahdi,
Thank you for report your discovery in vpp_sswan, unfortunately we haven't see
this memory growth issue in our end.
If my understanding is correct, the stat_segment_connect function should be
called only if you want to see how many packets and bytes were processed by
each SA, and the
Hi,
I used the plugin resided in `extras/vpp_sswan` on both 5.9.8 and 5.8.2
Strongswan versions. All functionalities are working great but after Child SAs
are established, there's a constant memory growth in charon process( Reaching
from 20MB RSS to 46MB RSS in 4 days, but this growth is visibl