invalid peer ID returned by kernel
-
It's a mismatch in peer lists between OpenVPN (userspace) and if_ovpn (kernel).
That can happen if we're requesting stats just as a peer is connecting or disconnecting. It's harmless. -
@kprovost thanks I can see the interrupts increasing with use, so I know it’s functional. Works great. Just that random error
-
From: Kristof Provost <kp@FreeBSD.org> It's possible for the buffer we provude for OVPN_GET_PEER_STATS to be too small. Handle the error, re-allocate a larger buffer and try again rather than failing. Signed-off-by: Kristof Provost <kpr...@ne...> --- src/openvpn/dco_freebsd.c | 16 ++++++++++++++-- 1 file changed, 14 insertions(+), 2 deletions(-) diff --git a/src/openvpn/dco_freebsd.c b/src/openvpn/dco_freebsd.c index 3ba1c817..577c65f8 100644 --- a/src/openvpn/dco_freebsd.c +++ b/src/openvpn/dco_freebsd.c @@ -698,7 +698,8 @@ dco_get_peer_stats_multi(dco_context_t *dco, struct multi_context *m) { struct ifdrv drv; - uint8_t buf[4096]; + uint8_t *buf = NULL; + size_t buf_size = 4096; nvlist_t *nvl; const nvlist_t *const *nvpeers; size_t npeers; @@ -712,17 +713,28 @@ dco_get_peer_stats_multi(dco_context_t *dco, struct multi_context *m) CLEAR(drv); snprintf(drv.ifd_name, IFNAMSIZ, "%s", dco->ifname); drv.ifd_cmd = OVPN_GET_PEER_STATS; - drv.ifd_len = sizeof(buf); + +retry: + buf = realloc(buf, buf_size); + drv.ifd_len = buf_size; drv.ifd_data = buf; ret = ioctl(dco->fd, SIOCGDRVSPEC, &drv); + if (ret && errno == ENOSPC) + { + buf_size *= 2; + goto retry; + } + if (ret) { + free(buf); msg(M_WARN | M_ERRNO, "Failed to get peer stats"); return -EINVAL; } nvl = nvlist_unpack(buf, drv.ifd_len, 0); + free(buf); if (!nvl) { msg(M_WARN, "Failed to unpack nvlist"); -- 2.43.0
Is there anyway to increase the buffer manually without updating ? I can not update and the next update removes the Safexcel support it no longer lists it
-
Is there anyway to increase the buffer manually without updating ?
No
I can not update and the next update removes the Safexcel support it no longer lists it
SafeXcel Crypto support has not been removed.
-
@kprovost What’s weird is the interrupt counters don’t run anymore in the newer version which is on the 2100 so I assume that it’s not functional
-
@JonathanLee I've just checked on my 2100 and it's happily using the safexcel0 device:
[24.11-BETA][root@pfSense.jupiter.sigsegv.be]/root: vmstat -i interrupt total rate gic0,p14:-ic_timer0 14103892 179 gic0,s2: iichb1 400 0 gic0,s11: uart0 4934 0 gic0,s20: safexcel0 622626 8 gic0,s21: safexcel0 454201 6 ...
What does the 'CPU Type' on the 'System Information' widget show?
For example, you may have selected IIMB as your cryptographic accelerator rather than SafeXcel.Mine shows:
IPsec-MB Crypto: Yes (inactive) SafeXcel Crypto: Yes (active)
-
@kprovost I use the command line info. vmstat -i | grep safexcel This shows no change or increase with the updated software vs the older version.
-
@kprovost I have both selected in the widget is that ok for VPN ?
-
Should they both not be enabled ?
-
@JonathanLee I mean, you can't use both at the same time. The data's only ever going to be processed by one of them. I'd have to go dig deep in the code to tell you how the selection is made if both are enabled, but it looks like in this case it ends up using IIMB.
IIMB is fine, but probably not quite as fast as SafeXcel. You're getting crypto acceleration either way, just in a different way.
-
@kprovost I marked the other one inactive
-
@kprovost do you enable max mss clamping ?
-
@kprovost thanks for your help I went from 18kbs-200 up to 580kbs that was significant with mss clamping max enabled