I have a vpn to type ipsec, configured for site to site built under strongswan, there are more than 100 tunnels established, but suddenly after x days there is no traffic, the policies are correct. On one side we have a hub and on the other the branch. When performing a ping from the hub to the branch, we have the following output. ping -I 10.165.112.248 10.10.55.1 PING 10.10.55.1 (10.10.55.1) from 10.165.112.248: 56(84) bytes of data. ping: sendmsg: Device or resource busy ping: sendmsg: Device or resource busy ping: sendmsg: Device or resource busy ping: sendmsg: Device or resource busy If you change the encryption algorithm of the tunnel after a while, you have traffic again, when monitoring the xfrm_proc code, we notice that the XfrmOutStateProtoError parameter is increased. If you restart linux it works again, but after x days the problem occurs again, ftrace was used to see what was running inside the kernel, this is the output when no traffic occurs 10) | __xfrm_policy_check() { 13) | __xfrm_policy_check() { 10) 0.153 us | xfrmi_decode_session [xfrm_interface](); 13) 0.168 us | xfrmi_decode_session [xfrm_interface](); 10) 0.213 us | __xfrm_decode_session(); 13) 0.208 us | __xfrm_decode_session(); 10) | xfrm_policy_lookup() { 10) | xfrm_policy_lookup_bytype() { 10) 0.117 us | xfrm_pol_bin_key(); 13) | xfrm_policy_lookup() { 13) | xfrm_policy_lookup_bytype() { 10) 0.434 us | } 10) | xfrm_policy_lookup_bytype() { 13) 0.127 us | xfrm_pol_bin_key(); 10) 0.107 us | xfrm_pol_bin_key(); 10) 0.331 us | } 13) 0.519 us | } 10) 1.088 us | } 13) | xfrm_policy_lookup_bytype() { 10) 2.162 us | } 13) 0.115 us | xfrm_pol_bin_key(); 10) | __xfrm_route_forward() { 10) 0.126 us | __xfrm_decode_session(); 13) 0.346 us | } 13) 1.192 us | } 10) | xfrm_lookup_with_ifid() { 13) 3.220 us | } 10) | xfrm_policy_lookup() { 10) | xfrm_policy_lookup_bytype() { 10) 0.131 us | xfrm_pol_bin_key(); 10) 0.354 us | } 10) | xfrm_policy_lookup_bytype() { 10) 0.105 us | xfrm_pol_bin_key(); 10) 0.329 us | } 10) 0.994 us | } 10) 0.116 us | xfrm_expand_policies(); 10) 1.442 us | } 10) 1.893 us | } 10) | __xfrm_policy_check() { 10) 0.140 us | xfrmi_decode_session [xfrm_interface](); 10) 0.161 us | __xfrm_decode_session(); 10) | xfrm_policy_lookup() { 10) | xfrm_policy_lookup_bytype() { 10) 0.117 us | xfrm_pol_bin_key(); 13) | __xfrm_policy_check() { 10) 0.394 us | } 13) 0.139 us | xfrmi_decode_session [xfrm_interface](); 10) | xfrm_policy_lookup_bytype() { 10) 0.108 us | xfrm_pol_bin_key(); 13) 0.216 us | __xfrm_decode_session(); 10) 0.337 us | } 10) 1.525 us | } 13) | xfrm_policy_lookup() { 10) 2.354 us | } 13) | xfrm_policy_lookup_bytype() { 13) 0.125 us | xfrm_pol_bin_key(); 13) 0.415 us | } 13) | xfrm_policy_lookup_bytype() { 13) 0.109 us | xfrm_pol_bin_key(); 13) 0.331 us | } 13) 1.057 us | } 13) 1.971 us | } 13) | __xfrm_route_forward() { 13) 0.121 us | __xfrm_decode_session(); 13) | xfrm_lookup_with_ifid() { 13) | xfrm_policy_lookup() { 13) | xfrm_policy_lookup_bytype() { 13) 0.142 us | xfrm_pol_bin_key(); 13) 0.365 us | } 13) | xfrm_policy_lookup_bytype() { 13) 0.106 us | xfrm_pol_bin_key(); 13) 0.332 us | } 13) 1.005 us | } 13) 0.116 us | xfrm_expand_policies(); 13) 1.493 us | } 13) 1.967 us | } And this is the output when the traffic occurs. 1) | esp_output_done [esp4]() { 1) 1.136 us | esp_ssg_unref.isra.0 [esp4](); 1) + 16.552 us | xfrm_output_resume(); 1) + 21.493 us | } ------------------------------------------ 1) kworker-5415 => <idle>-0 ------------------------------------------ 1) 0.732 us | xfrm_dev_backlog(); 7) | xfrm_lookup_route() { 7) | xfrm_lookup_with_ifid() { 7) | xfrm_policy_lookup() { 7) | xfrm_policy_lookup_bytype() { 7) 0.391 us | xfrm_pol_bin_key(); 7) 1.781 us | } 7) | xfrm_policy_lookup_bytype() { 7) 0.344 us | xfrm_pol_bin_key(); 7) 1.129 us | } 7) 4.116 us | } 7) 0.375 us | xfrm_expand_policies(); 7) 6.147 us | } 7) 8.707 us | } 7) 1.109 us | xfrm_dst_check(); 7) 0.622 us | xfrm_mtu(); 7) | xfrm4_output() { 7) | __xfrm4_output() { 7) 0.444 us | xfrm_state_afinfo_get_rcu(); 7) | xfrm4_output_finish() { 7) | xfrm_output() { 7) 0.374 us | xfrm_dev_offload_ok(); 7) | xfrm_output_resume() { 7) | xfrm_inner_extract_output() { 7) 0.375 us | xfrm_state_afinfo_get_rcu(); 7) | xfrm4_extract_output() { 7) 0.435 us | xfrm_mtu(); 7) 0.354 us | xfrm4_extract_header(); 7) 1.934 us | } 7) 3.488 us | } 7) 0.385 us | xfrm_state_check_expire(); 7) 0.608 us | xfrm_replay_overflow_offload(); 7) | esp_output [esp4]() { 7) | esp_output_head [esp4]() { 7) 0.391 us | esp_output_fill_trailer [esp4](); 7) 1.317 us | } 7) | esp_output_tail [esp4]() { 7) 0.528 us | esp_alloc_tmp [esp4](); 7) 8.830 us | } 7) + 11.747 us | } 7) + 19.074 us | } 7) + 20.888 us | } 7) + 21.774 us | } 7) + 23.561 us | } 7) + 25.048 us | } Kernel 5.4.113-1.el7.elrepo.x86_64
Created attachment 304596 [details] Some extra information.
(In reply to Wallas from comment #0) > I have a vpn to type ipsec, configured for site to site built under > strongswan, there are more than 100 tunnels established, but suddenly after > x days there is no traffic, the policies are correct. On one side we have a > hub and on the other the branch. When performing a ping from the hub to the > branch, we have the following output. > > ping -I 10.165.112.248 10.10.55.1 > PING 10.10.55.1 (10.10.55.1) from 10.165.112.248: 56(84) bytes of data. > ping: sendmsg: Device or resource busy > ping: sendmsg: Device or resource busy > ping: sendmsg: Device or resource busy > ping: sendmsg: Device or resource busy > > If you change the encryption algorithm of the tunnel after a while, you have > traffic again, when monitoring the xfrm_proc code, we notice that the > XfrmOutStateProtoError parameter is increased. > > If you restart linux it works again, but after x days the problem occurs > again, ftrace was used to see what was running inside the kernel, this is > the output when no traffic occurs > > 10) | __xfrm_policy_check() { > 13) | __xfrm_policy_check() { > 10) 0.153 us | xfrmi_decode_session [xfrm_interface](); > 13) 0.168 us | xfrmi_decode_session [xfrm_interface](); > 10) 0.213 us | __xfrm_decode_session(); > 13) 0.208 us | __xfrm_decode_session(); > 10) | xfrm_policy_lookup() { > 10) | xfrm_policy_lookup_bytype() { > 10) 0.117 us | xfrm_pol_bin_key(); > 13) | xfrm_policy_lookup() { > 13) | xfrm_policy_lookup_bytype() { > 10) 0.434 us | } > 10) | xfrm_policy_lookup_bytype() { > 13) 0.127 us | xfrm_pol_bin_key(); > 10) 0.107 us | xfrm_pol_bin_key(); > 10) 0.331 us | } > 13) 0.519 us | } > 10) 1.088 us | } > 13) | xfrm_policy_lookup_bytype() { > 10) 2.162 us | } > 13) 0.115 us | xfrm_pol_bin_key(); > 10) | __xfrm_route_forward() { > 10) 0.126 us | __xfrm_decode_session(); > 13) 0.346 us | } > 13) 1.192 us | } > 10) | xfrm_lookup_with_ifid() { > 13) 3.220 us | } > 10) | xfrm_policy_lookup() { > 10) | xfrm_policy_lookup_bytype() { > 10) 0.131 us | xfrm_pol_bin_key(); > 10) 0.354 us | } > 10) | xfrm_policy_lookup_bytype() { > 10) 0.105 us | xfrm_pol_bin_key(); > 10) 0.329 us | } > 10) 0.994 us | } > 10) 0.116 us | xfrm_expand_policies(); > 10) 1.442 us | } > 10) 1.893 us | } > 10) | __xfrm_policy_check() { > 10) 0.140 us | xfrmi_decode_session [xfrm_interface](); > 10) 0.161 us | __xfrm_decode_session(); > 10) | xfrm_policy_lookup() { > 10) | xfrm_policy_lookup_bytype() { > 10) 0.117 us | xfrm_pol_bin_key(); > 13) | __xfrm_policy_check() { > 10) 0.394 us | } > 13) 0.139 us | xfrmi_decode_session [xfrm_interface](); > 10) | xfrm_policy_lookup_bytype() { > 10) 0.108 us | xfrm_pol_bin_key(); > 13) 0.216 us | __xfrm_decode_session(); > 10) 0.337 us | } > 10) 1.525 us | } > 13) | xfrm_policy_lookup() { > 10) 2.354 us | } > 13) | xfrm_policy_lookup_bytype() { > 13) 0.125 us | xfrm_pol_bin_key(); > 13) 0.415 us | } > 13) | xfrm_policy_lookup_bytype() { > 13) 0.109 us | xfrm_pol_bin_key(); > 13) 0.331 us | } > 13) 1.057 us | } > 13) 1.971 us | } > 13) | __xfrm_route_forward() { > 13) 0.121 us | __xfrm_decode_session(); > 13) | xfrm_lookup_with_ifid() { > 13) | xfrm_policy_lookup() { > 13) | xfrm_policy_lookup_bytype() { > 13) 0.142 us | xfrm_pol_bin_key(); > 13) 0.365 us | } > 13) | xfrm_policy_lookup_bytype() { > 13) 0.106 us | xfrm_pol_bin_key(); > 13) 0.332 us | } > 13) 1.005 us | } > 13) 0.116 us | xfrm_expand_policies(); > 13) 1.493 us | } > 13) 1.967 us | } > > And this is the output when the traffic occurs. > > > 1) | esp_output_done [esp4]() { > 1) 1.136 us | esp_ssg_unref.isra.0 [esp4](); > 1) + 16.552 us | xfrm_output_resume(); > 1) + 21.493 us | } > ------------------------------------------ > 1) kworker-5415 => <idle>-0 > ------------------------------------------ > > 1) 0.732 us | xfrm_dev_backlog(); > 7) | xfrm_lookup_route() { > 7) | xfrm_lookup_with_ifid() { > 7) | xfrm_policy_lookup() { > 7) | xfrm_policy_lookup_bytype() { > 7) 0.391 us | xfrm_pol_bin_key(); > 7) 1.781 us | } > 7) | xfrm_policy_lookup_bytype() { > 7) 0.344 us | xfrm_pol_bin_key(); > 7) 1.129 us | } > 7) 4.116 us | } > 7) 0.375 us | xfrm_expand_policies(); > 7) 6.147 us | } > 7) 8.707 us | } > 7) 1.109 us | xfrm_dst_check(); > 7) 0.622 us | xfrm_mtu(); > 7) | xfrm4_output() { > 7) | __xfrm4_output() { > 7) 0.444 us | xfrm_state_afinfo_get_rcu(); > 7) | xfrm4_output_finish() { > 7) | xfrm_output() { > 7) 0.374 us | xfrm_dev_offload_ok(); > 7) | xfrm_output_resume() { > 7) | xfrm_inner_extract_output() { > 7) 0.375 us | xfrm_state_afinfo_get_rcu(); > 7) | xfrm4_extract_output() { > 7) 0.435 us | xfrm_mtu(); > 7) 0.354 us | xfrm4_extract_header(); > 7) 1.934 us | } > 7) 3.488 us | } > 7) 0.385 us | xfrm_state_check_expire(); > 7) 0.608 us | xfrm_replay_overflow_offload(); > 7) | esp_output [esp4]() { > 7) | esp_output_head [esp4]() { > 7) 0.391 us | esp_output_fill_trailer [esp4](); > 7) 1.317 us | } > 7) | esp_output_tail [esp4]() { > 7) 0.528 us | esp_alloc_tmp [esp4](); > 7) 8.830 us | } > 7) + 11.747 us | } > 7) + 19.074 us | } > 7) + 20.888 us | } > 7) + 21.774 us | } > 7) + 23.561 us | } > 7) + 25.048 us | } > > > > Kernel 5.4.113-1.el7.elrepo.x86_64 Does this also happen on latest mainline (v6.5-rc1)?
(In reply to Bagas Sanjaya from comment #2) > (In reply to Wallas from comment #0) > > I have a vpn to type ipsec, configured for site to site built under > > strongswan, there are more than 100 tunnels established, but suddenly after > > x days there is no traffic, the policies are correct. On one side we have a > > hub and on the other the branch. When performing a ping from the hub to the > > branch, we have the following output. > > > > ping -I 10.165.112.248 10.10.55.1 > > PING 10.10.55.1 (10.10.55.1) from 10.165.112.248: 56(84) bytes of data. > > ping: sendmsg: Device or resource busy > > ping: sendmsg: Device or resource busy > > ping: sendmsg: Device or resource busy > > ping: sendmsg: Device or resource busy > > > > If you change the encryption algorithm of the tunnel after a while, you > have > > traffic again, when monitoring the xfrm_proc code, we notice that the > > XfrmOutStateProtoError parameter is increased. > > > > If you restart linux it works again, but after x days the problem occurs > > again, ftrace was used to see what was running inside the kernel, this is > > the output when no traffic occurs > > > > 10) | __xfrm_policy_check() { > > 13) | __xfrm_policy_check() { > > 10) 0.153 us | xfrmi_decode_session [xfrm_interface](); > > 13) 0.168 us | xfrmi_decode_session [xfrm_interface](); > > 10) 0.213 us | __xfrm_decode_session(); > > 13) 0.208 us | __xfrm_decode_session(); > > 10) | xfrm_policy_lookup() { > > 10) | xfrm_policy_lookup_bytype() { > > 10) 0.117 us | xfrm_pol_bin_key(); > > 13) | xfrm_policy_lookup() { > > 13) | xfrm_policy_lookup_bytype() { > > 10) 0.434 us | } > > 10) | xfrm_policy_lookup_bytype() { > > 13) 0.127 us | xfrm_pol_bin_key(); > > 10) 0.107 us | xfrm_pol_bin_key(); > > 10) 0.331 us | } > > 13) 0.519 us | } > > 10) 1.088 us | } > > 13) | xfrm_policy_lookup_bytype() { > > 10) 2.162 us | } > > 13) 0.115 us | xfrm_pol_bin_key(); > > 10) | __xfrm_route_forward() { > > 10) 0.126 us | __xfrm_decode_session(); > > 13) 0.346 us | } > > 13) 1.192 us | } > > 10) | xfrm_lookup_with_ifid() { > > 13) 3.220 us | } > > 10) | xfrm_policy_lookup() { > > 10) | xfrm_policy_lookup_bytype() { > > 10) 0.131 us | xfrm_pol_bin_key(); > > 10) 0.354 us | } > > 10) | xfrm_policy_lookup_bytype() { > > 10) 0.105 us | xfrm_pol_bin_key(); > > 10) 0.329 us | } > > 10) 0.994 us | } > > 10) 0.116 us | xfrm_expand_policies(); > > 10) 1.442 us | } > > 10) 1.893 us | } > > 10) | __xfrm_policy_check() { > > 10) 0.140 us | xfrmi_decode_session [xfrm_interface](); > > 10) 0.161 us | __xfrm_decode_session(); > > 10) | xfrm_policy_lookup() { > > 10) | xfrm_policy_lookup_bytype() { > > 10) 0.117 us | xfrm_pol_bin_key(); > > 13) | __xfrm_policy_check() { > > 10) 0.394 us | } > > 13) 0.139 us | xfrmi_decode_session [xfrm_interface](); > > 10) | xfrm_policy_lookup_bytype() { > > 10) 0.108 us | xfrm_pol_bin_key(); > > 13) 0.216 us | __xfrm_decode_session(); > > 10) 0.337 us | } > > 10) 1.525 us | } > > 13) | xfrm_policy_lookup() { > > 10) 2.354 us | } > > 13) | xfrm_policy_lookup_bytype() { > > 13) 0.125 us | xfrm_pol_bin_key(); > > 13) 0.415 us | } > > 13) | xfrm_policy_lookup_bytype() { > > 13) 0.109 us | xfrm_pol_bin_key(); > > 13) 0.331 us | } > > 13) 1.057 us | } > > 13) 1.971 us | } > > 13) | __xfrm_route_forward() { > > 13) 0.121 us | __xfrm_decode_session(); > > 13) | xfrm_lookup_with_ifid() { > > 13) | xfrm_policy_lookup() { > > 13) | xfrm_policy_lookup_bytype() { > > 13) 0.142 us | xfrm_pol_bin_key(); > > 13) 0.365 us | } > > 13) | xfrm_policy_lookup_bytype() { > > 13) 0.106 us | xfrm_pol_bin_key(); > > 13) 0.332 us | } > > 13) 1.005 us | } > > 13) 0.116 us | xfrm_expand_policies(); > > 13) 1.493 us | } > > 13) 1.967 us | } > > > > And this is the output when the traffic occurs. > > > > > > 1) | esp_output_done [esp4]() { > > 1) 1.136 us | esp_ssg_unref.isra.0 [esp4](); > > 1) + 16.552 us | xfrm_output_resume(); > > 1) + 21.493 us | } > > ------------------------------------------ > > 1) kworker-5415 => <idle>-0 > > ------------------------------------------ > > > > 1) 0.732 us | xfrm_dev_backlog(); > > 7) | xfrm_lookup_route() { > > 7) | xfrm_lookup_with_ifid() { > > 7) | xfrm_policy_lookup() { > > 7) | xfrm_policy_lookup_bytype() { > > 7) 0.391 us | xfrm_pol_bin_key(); > > 7) 1.781 us | } > > 7) | xfrm_policy_lookup_bytype() { > > 7) 0.344 us | xfrm_pol_bin_key(); > > 7) 1.129 us | } > > 7) 4.116 us | } > > 7) 0.375 us | xfrm_expand_policies(); > > 7) 6.147 us | } > > 7) 8.707 us | } > > 7) 1.109 us | xfrm_dst_check(); > > 7) 0.622 us | xfrm_mtu(); > > 7) | xfrm4_output() { > > 7) | __xfrm4_output() { > > 7) 0.444 us | xfrm_state_afinfo_get_rcu(); > > 7) | xfrm4_output_finish() { > > 7) | xfrm_output() { > > 7) 0.374 us | xfrm_dev_offload_ok(); > > 7) | xfrm_output_resume() { > > 7) | xfrm_inner_extract_output() { > > 7) 0.375 us | xfrm_state_afinfo_get_rcu(); > > 7) | xfrm4_extract_output() { > > 7) 0.435 us | xfrm_mtu(); > > 7) 0.354 us | xfrm4_extract_header(); > > 7) 1.934 us | } > > 7) 3.488 us | } > > 7) 0.385 us | xfrm_state_check_expire(); > > 7) 0.608 us | xfrm_replay_overflow_offload(); > > 7) | esp_output [esp4]() { > > 7) | esp_output_head [esp4]() { > > 7) 0.391 us | esp_output_fill_trailer [esp4](); > > 7) 1.317 us | } > > 7) | esp_output_tail [esp4]() { > > 7) 0.528 us | esp_alloc_tmp [esp4](); > > 7) 8.830 us | } > > 7) + 11.747 us | } > > 7) + 19.074 us | } > > 7) + 20.888 us | } > > 7) + 21.774 us | } > > 7) + 23.561 us | } > > 7) + 25.048 us | } > > > > > > > > Kernel 5.4.113-1.el7.elrepo.x86_64 > > Does this also happen on latest mainline (v6.5-rc1)? I can't tell, it wasn't tested in that version, but I need to understand if this has already been fixed or not.
We try the new kernel versions + path: Kernel: Linux 5.4.249-1.el7.elrepo.x86_64 Kernel: Linux 6.4.11.el7.elrepo.x86_64 https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/net/xfrm?h=v6.5.9&id=de0bfd6026c85de3a0a0db2766ab740733d1631e https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/net/xfrm?h=v6.5.9&id=de0bfd6026c85de3a0a0db2766ab740733d1631e https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/net/xfrm?h=v6.5.9&id=071bba39638f6532040aca3bdabba469186f631c https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/net/xfrm?h=v6.5.9&id=071bba39638f6532040aca3bdabba469186f631c https://teams.microsoft.com/l/message/19:e0ecff19-2bea-4982-862d-6e9145bab0aa_ea564d57-9897-4fac-b82e-b00f9e20b958@unq.gbl.spaces/1701886117615?context=%7B%22contextType%22%3A%22chat%22%7D We tried several of their suggestions, but unfortunately, nothing has resolved our issue.
Now, we are testing these configurations: #Disable aesni_intel modeule lsmod |grep -i aesni_intel aesni_intel 372736 4 vi /boot/grub2/grub.cfg Foi adicionado "module_blacklist=aesni_intel" cat /boot/grub2/grub.cfg |grep -i aesni_intel linux16 /vmlinuz-5.4.113-1.el7.elrepo.x86_64 root=UUID=222c8741-7ce5-4f57-95b6-f435fce5b9b9 ro vconsole.font=latarcyrheb-sun16 vconsole.keymap=us rd.luks.uuid=luks-83730611-a1fc-492a-af40-bf3555dae23f rd.luks.key=/etc/._key rd.luks.options=allow-discards biosdevname=0 splash=silent maxcpus=2 possible_cpus=2 mem=5G quiet qat_c3xxx.blacklist=yes qat_c62x.blacklist=yes rdblacklist=qat_c3xxx rdblacklist=qat_c62x module_blacklist=qat_c3xxx module_blacklist=qat_c62x module_blacklist=aesni_intel net.ifnames=0 elevator=noop rd.plymouth=0 plymouth.enable=0 console=tty0 console=ttyS0,115200 depmod reboot lsmod |grep -i aesni_intel ------ On /etc/strongswan/strongswan.d/charon/kernel-netlink.conf # Whether to perform concurrent Netlink XFRM queries on a single socket. parallel_xfrm = yes # Whether to always use XFRM_MSG_UPDPOLICY to install policies. policy_update = yes 2 - /etc/strongswan/strongswan.d/charon.conf (mudar de 32 para zero) replay_window = 0 3 - /etc/strongswan/swanctl/swanctl.conf # IPsec replay window to configure for this CHILD_SA. # replay_window = 32 replay_window = 0 systemctl restart strongswan On next week we are checking the result.
Dear Kernel Maintainers, I am writing to provide an update on the issue previously reported. Despite undertaking various actions to try to resolve the matter, as listed in the previous post, unfortunately, none have been successful so far. Each of these actions was followed by rigorous testing, but the problem continues to persist. We appreciate any feedback or suggestions that might have stemmed from our earlier reports. As a next step, we plan to test with Kernel version 4.19.12. We believe this version might offer a solution, or at least provide more information to help diagnose the problem in more depth. Any additional guidance or recommendation regarding this plan would be extremely valuable. Thank you for your continued assistance and dedication to maintaining the stability and efficiency of the Kernel. We will keep Bugzilla updated with our findings after this next attempt. We are counting on your help. Sincerely,
Kernel bugzilla is not the primary bug reporting and fixing mechanism for networking in Linux. It is only a backdoor conduit to the real discussions on netdev@vger.kernel.org. Do not expect anything here. These are not the droids you are looking for.
Thanks Stephen, we will contact them!!
Hi, For now we will unable pcrypt to see if the bug is solved. But we need to keep using pcrypt as it is import for the performance of the solution. Can you help us solving this bug in the pcrypt?
Hi, I would like to extend my gratitude for suggesting the deactivation of the pcrypt module in our IPsec VPN setup. Following your recommendation, I am pleased to report that the issue we were experiencing with VPN hang-ups has since ceased to occur. This adjustment has proven to be an effective solution to the challenges we were facing. Furthermore, it is noteworthy to mention that we have observed no degradation in the VPN IPsec throughput following the module’s deactivation. This was an initial concern for us, but practical outcomes have demonstrated that the overall system performance has remained consistent and reliable. With that said, I am curious to know whether you were previously aware of issues related to the use of pcrypt in the context we discussed. If so, could you share how these issues are being addressed? We are keen to better understand the long-term implications of this change and whether there are plans to resolve the underlying bug with pcrypt and padata. Your support and guidance on this matter have been immensely appreciated. Your expertise has been crucial in helping us navigate this technical issue. I look forward to your additional insights and any recommendations you may have for us. Best regards,