Messages

Got the same with 26.7. The disk widget sometimes remains larger when refreshing with F5 and using Edge.

Ah that explains. Thanks

Thanks Franco that cleared the warning but strange that it got installed in the first place if it isn't coming from Opnsense. Must have been one of the plugins i am running I guess. Never installed any tools or whatever.
Oh well..

It's gone now :)

Hi there, after the upgrade to 26.7 I get multiple times per second the following crashmessage
[15-Jul-2026 16:16:04 UTC] PHP Warning:  PHP Startup: Unable to load dynamic library 'mongodb.so' (tried: /usr/local/lib/php/20250925/mongodb.so (Cannot open "/usr/local/lib/php/20250925/mongodb.so"), /usr/local/lib/php/20250925/mongodb.so.so (Cannot open "/usr/local/lib/php/20250925/mongodb.so.so")) in Unknown on line 0


I did uninstall ZA + the repository just to be sure it wasn't the cause, rebooted but still get the same warning multiple times every second.
I also found this topic
https://forum.opnsense.org/index.php?topic=52379.0

Though not the same error but there it also reports problems with mongodb. Could be coincidence of course. Any clue which plugin might be causing this or what troubleshooting steps can be taken? I checked the known issues so to be sure it wasnt ZA I removed all components.

User-Agent Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/150.0.0.0 Safari/537.36 Edg/150.0.0.0
FreeBSD 15.1-RELEASE-p1 stable/26.7-n283674-12334a596709 SMP amd64
OPNsense 26.7 821598263
Plugins os-acme-client-4.16_1 os-bind-1.34_3 os-clamav-1.8.1 os-cpu-microcode-intel-1.1 os-etpro-telemetry-1.8_1 os-freeradius-1.10.2 os-igmp-proxy-1.5_6 os-nextcloud-backup-1.2 os-nginx-1.36_3 os-postfix-1.24.1 os-redis-1.1_4 os-rspamd-1.13_2 os-smart-2.4 os-wazuh-agent-1.3_1
Time Wed, 15 Jul 2026 18:16:44 +0200
OpenSSL 3.5.7
Python 3.13.14
PHP 8.5.8

I've got the same issue.
I'm running ISC DHCP on separate containers. This is working fine with DHCrelay on IPv4.
On IPv6, the DHCP servers are failing to assign addresses because they cannot map the incoming relayed DHCP request to a DHCP pool.
I also saw the OPNsense DHCrelay set the link-address to it's link-local address. If it would send it's GUA address instead, the DHCP server could map it to the correct GUA pool.

I got the same problem as you described. For reasons I am running a Kea DHCP server in a different subnet as the clients are on a different machine so I relay the traffic via opnsense's dhcp relay. The problem is that it uses the link-local address instead of the global ipv6 as link-address to forward the relay's and Kea won't be able to properly select a subnet. I do use correct class selection in Kea for subnet selection but it doesn't come to that stage yet.

/edit
When I go through the RFC 8415 it states that using a link-local address is not recommended but GUA is. Kea expects a GUA address as link-address. It is not a hard requirement though that a relay agent MUST use a GUA and may use a link-local instead.
https://datatracker.ietf.org/doc/rfc8415/

19.1.1.  Relaying a Message from a Client

   If the relay agent received the message to be relayed from a client,
   the relay agent places a globally scoped unicast address (i.e., GUA
   or ULA) from a prefix assigned to the link on which the client should
   be assigned leases into the link-address field.  If such an address
   is not available, the relay agent may set the link-address field to a
   link-local address from the interface on which the original message
   was received.  This is not recommended, as it may require that
   additional information be provided in the server configuration.  See
   Section 3.2 of [RFC7969] for a detailed discussion.

   This address will be used by the server to determine the link from
   which the client should be assigned leases and other configuration
   information.

   The hop-count value in the Relay-forward message is set to 0.

   If the relay agent cannot use the address in the link-address field
   to identify the interface through which the response to the client
   will be relayed, the relay agent MUST include an Interface-Id option
   (see Section 21.18) in the Relay-forward message.  The server will
   include the Interface-Id option in its Relay-reply message.  The
   relay agent sets the link-address field as described earlier in this
   subsection, regardless of whether the relay agent includes an
   Interface-Id option in the Relay-forward message.

And RFC 7969 has also some discussion about this
https://datatracker.ietf.org/doc/html/rfc7969#autoid-5

3.2.  DHCPv6-Specific Behavior

   The DHCPv6 protocol [RFC3315] defines two core mechanisms that allow
   a server to distinguish which link the relay agent is connected to.
   The first mechanism is the link-address field in the Relay-forward
   and Relay-reply messages.  The link-address field uniquely identifies
   the link and should not be mistaken for a link-local address.  In
   normal circumstances, this is the solution that is easiest to
   maintain, as existing address assignments can be used and no
   additional administrative actions (like assigning dedicated
   identifiers for each relay agent, making sure they are unique, and
   maintaining a list of such identifiers) are needed.  It requires,
   however, for the relay agent to have an address with a scope larger
   than link-local configured on its client-facing interface.