os-frr: kern.ipc.maxsockbuf default too low for FRR 10, causes data-plane issues

**Important notices** Before you add a new report, we ask you kindly to acknowledge the following: - [x] I have read the contributing guide lines at https://github.com/opnsense/plugins/blob/master/CONTRIBUTING.md - [x] I have searched the existing issues, open and closed, and I'm convinced that mine is new - well, no, but I can't reopen #4840 - [x] The title contains the plugin to which this issue belongs **Describe the bug** os-frr ships with the FreeBSD default `kern.ipc.maxsockbuf` (2 MiB), which is too small for FRR 10's internal socket buffer requests (16 MiB per socket). FRR's daemons (watchfrr, mgmtd, ospfd, zebra) log continuous errors: ``` setsockopt_so_recvbuf: fd N: SO_RCVBUF set to 8388608 (requested 16777216) setsockopt_so_sendbuf: fd N: SO_SNDBUF set to 8388608 (requested 16777216) ``` In my case this was not just log noise - I observed intermittent data-plane failures (which actually triggered my investigation in the first place) and found the kernel FIB not consistently picking up routes that FRR's RIB had marked as installed (`O>*`). Restarting FRR temporarily resolved things until the next adjacency event. After raising `kern.ipc.maxsockbuf` to 33554432 (32 MiB) via System - Settings - Tunables and rebooting, the errors stopped and the data-plane intermittency disappeared. This issue has been reported and discussed before: - https://forum.opnsense.org/index.php?topic=48261.0 - Plugin issue #4840 (closed) where Monviech confirms 33554432 is the value needed for FRR 10. I'm filing a new issue rather than reopening that one because (a) #4840 was primarily about an OSPFv3 area assignment bug that got fixed, with the buffer issue only mentioned as a side-note in comments, and (b) I don't have permission to reopen it. I'd suggest the os-frr plugin either: 1. ship a default `kern.ipc.maxsockbuf=33554432` Tunable when the plugin is installed/enabled, or 2. surface a clear warning in the plugin UI / documentation that this tunable must be set, with the correct value for FRR 10. The current situation is that users hit it, log spam looks cosmetic, but the underlying buffer reduction can cause subtle and hard-to-diagnose data-plane issues. **To Reproduce** 1. Fresh OPNsense 26.1.2 install with default tunables 2. Install os-frr plugin, enable FRR with OSPF on at least one interface 3. Bring up an OSPF adjacency to a peer 4. Observe `/var/log/frr/frr.log` and system log: continuous `setsockopt_so_recvbuf` / `setsockopt_so_sendbuf` errors, capping at exactly 8388608 bytes despite a 16777216 byte request 5. Routes not turning up in the kernel routing table were a phenomenon I observed, I can't promise that is 100% reproducible, especially because restarting frr a few times made them turn up eventually. **Expected behavior** FRR should be able to allocate the socket buffers it requests, either because: - the plugin sets `kern.ipc.maxsockbuf` to a sufficient value at install time, or - the user is clearly informed that they must set this tunable manually, with the correct value for the current FRR version. **Relevant log files** From `/var/log/frr/frr.log` (sample, repeats every second): ``` 2026/04/25 17:18:14 [N945F-NP6FF][EC 100663299] setsockopt_so_sendbuf: fd 8: SO_SNDBUF set to 8388608 (requested 16777216) 2026/04/25 17:18:14 [N945F-NP6FF][EC 100663299] setsockopt_so_sendbuf: fd 20: SO_SNDBUF set to 8388608 (requested 16777216) ``` After setting `kern.ipc.maxsockbuf=33554432` and rebooting: ``` sysctl kern.ipc.maxsockbuf kern.ipc.maxsockbuf: 33554432 ``` No more errors. **Additional context** FreeBSD reduces the effective per-socket maximum below `kern.ipc.maxsockbuf` by an mbuf overhead factor: ``` sb_max_adj = kern.ipc.maxsockbuf * MCLBYTES / (MSIZE + MCLBYTES) = maxsockbuf * 2048 / 2304 (on amd64) ~= maxsockbuf * 0.889 ``` The cap is enforced in `sbreserve_locked()` in `sys/kern/uipc_sockbuf.c` (`if (cc > sb_max_adj) return (0);`). So even setting `maxsockbuf = 16777216` (16 MiB) leaves the effective per-socket max at ~14.9 MiB, which still rejects FRR's 16 MiB request. Strictly, the minimum that satisfies the formula is `16777216 * 2304 / 2048 = 18874368` (~18 MiB). I can't fully account for why my system caps at exactly 8 MiB rather than ~14.9 MiB at the intermediate values I tried (17 MiB) - there may be an additional FRR-side halve-and-retry behavior, or another reduction layer I'm not aware of. Either way, 32 MiB clears all hurdles empirically and matches the value Monviech suggested in #4840. Worth noting: FRR's error message gives no hint whatsoever about what the user should tune, or that there even is a problem with a functionality impact, which is why this issue keeps catching people. A separate FRR upstream improvement could help, but for me, a fix in the OPNsense plugin would solve my pain. **Environment** OPNsense 26.1.2_5-amd64 FreeBSD 14.3-RELEASE-p8 OpenSSL 3.0.19 FRR plugin 1.51 Hardware: Fujitsu D3400-A1 board, Intel Core i3-6100 @ 3.70GHz, 4 GB RAM