invalid peer ID returned by kernel

JonathanLee

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

kprovost

@JonathanLee

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.

JonathanLee

@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

kprovost

@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)

JonathanLee

@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.

JonathanLee

@kprovost I have both selected in the widget is that ok for VPN ?

JonathanLee

@kprovost

Should they both not be enabled ?

kprovost

@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.

JonathanLee

@kprovost I marked the other one inactive

JonathanLee

@kprovost do you enable max mss clamping ?

JonathanLee

@kprovost thanks for your help I went from 18kbs-200 up to 580kbs that was significant with mss clamping max enabled