Messages

OPNsense 24.7.b_127-amd64
FreeBSD 13.2-RELEASE-p11
OpenSSL 3.0.14
Intel(R) Celeron(R) J4105 CPU @ 1.50GHz (4 cores, 4 threads)

Hi, Since upgrading to the latest development version on the 20th June, I'm having it appears a runaway process trip monit into alerting at exactly 3:06am every day that eventually consumes all the resources on my router. I can't even access the GUI or remote in via SSH, just sits and times out, so have to hard reset.

I have Monit running and that is what alerted me to this issue, some examples at the bottom of this thread, my inbox fills up with these alerts by the time I wake up and can take some action on it.

The internet appears to keep running for me in the background while these alerts are sent and me being locked out from accessing the GUI. Yesterday I rebooted the router around 8 am before work and alerts stopped, all was good again. This morning I had a lie in and the internet went off completely at 10am, so the runaway process does eventually take out my router it seems if left unchecked.

I've got nothing in the cron to run at 3:06am, only thing I have is an ACME certificate renew job that runs on the 1st of every month.

I've run the Audit for Health and Connectivity, no issues shown, when I run security it mentions "openvpn-2.6.10 is vulnerable".

[Alert from 21st]
Resource limit matched Service OPNsense.localdomain

        Date:        Fri, 21 Jun 2024 03:06:37
        Action:      alert
        Host:        OPNsense.localdomain
        Description: loadavg (1min) of 2.8 matches resource limit [loadavg (1min) > 2.0]

Your faithful employee,
Monit

Resource limit matched Service OPNsense.localdomain

        Date:        Fri, 21 Jun 2024 03:08:39
        Action:      alert
        Host:        OPNsense.localdomain
        Description: cpu usage of 99.5% matches resource limit [cpu usage > 75.0%]

Your faithful employee,
Monit

[Alert from 22nd]
Resource limit matched Service OPNsense.localdomain

        Date:        Sat, 22 Jun 2024 03:06:38
        Action:      alert
        Host:        OPNsense.localdomain
        Description: loadavg (1min) of 3.3 matches resource limit [loadavg (1min) > 2.0]

Your faithful employee,
Monit

Just been looking at the reporting health graphs, and found some supporting evidence. I've attached the graphs for memory, CPU Temp, Processer and States and it looks like @3:02 all capturing of stats just stops, memory table below as an example. Up until that point however everything looks to be ticking along nicely, and then it hits an iceberg and sinks fast. I can't add the mbuf graph, but that is similar to all the others, flatlined graph with mbuf usage  showing 10k as current which is nothing.

659   Sat Jun 22 2024 03:01:00 GMT+0100 (British Summer Time)   0.61510877435   5.7981159604   82.780266382   0   7.9750526226
660   Sat Jun 22 2024 03:02:00 GMT+0100 (British Summer Time)   0   0   0   0   0
661   Sat Jun 22 2024 03:03:00 GMT+0100 (British Summer Time)   0   0   0   0   0
662   Sat Jun 22 2024 03:04:00 GMT+0100 (British Summer Time)   0   0   0   0   0
663   Sat Jun 22 2024 03:05:00 GMT+0100 (British Summer Time)   0   0   0   0   0
664   Sat Jun 22 2024 03:06:00 GMT+0100 (British Summer Time)   0   0   0   0   0
665   Sat Jun 22 2024 03:07:00 GMT+0100 (British Summer Time)   0   0   0   0   0
.....

Any thoughts on how best to diagnose this one, I haven't got logging switched on to save my SSD, so can't offer any further breadcrumbs at this time?

Thanks
S.

Any ideas how to get around this upgrade issue please?

Type   opnsense-devel   
Version   24.1.a_361

Upgrade Logs:

***GOT REQUEST TO UPDATE***
Currently running OPNsense 24.1.a_361 at Wed Oct 25 09:44:43 BST 2023
Updating OPNsense repository catalogue...
OPNsense repository is up to date.
All repositories are up to date.
Updating OPNsense repository catalogue...
OPNsense repository is up to date.
All repositories are up to date.
Checking for upgrades (115 candidates): .......... done
Processing candidates (115 candidates): ..... done
Checking integrity... done (1 conflicting)
  - openssl111-1.1.1w conflicts with openssl-1.1.1w,1 on /usr/local/bin/c_rehash
Cannot solve problem using SAT solver, trying another plan
Checking integrity... done (0 conflicting)
The following 56 package(s) will be affected (of 0 checked):

Installed packages to be REMOVED:
   mpd5: 5.9_16
   openssl: 1.1.1w,1
   opnsense-devel: 24.1.a_361

New packages to be INSTALLED:
   openssl111: 1.1.1w

Installed packages to be UPGRADED:
   curl: 8.3.0 -> 8.4.0
   easy-rsa: 3.1.6 -> 3.1.7
   gettext-runtime: 0.22_1 -> 0.22.3
   libnet: 1.2,1 -> 1.3,1
   libnghttp2: 1.56.0 -> 1.57.0
   lighttpd: 1.4.71 -> 1.4.72
   nss: 3.93 -> 3.94
   opnsense-lang: 23.7.4 -> 23.7.7
   opnsense-update: 23.7.4 -> 23.7.7
   os-ddclient: 1.16 -> 1.16_1
   perl5: 5.34.1_3 -> 5.36.1_1
   py39-boto3: 1.28.62 -> 1.28.63
   py39-botocore: 1.31.62 -> 1.31.63
   py39-dns-lexicon: 3.15.0 -> 3.16.0
   py39-numpy: 1.25.0,1 -> 1.25.0_2,1
   py39-outcome: 1.2.0 -> 1.3.0
   suricata-devel: 7.0.1 -> 7.0.2
   unbound: 1.18.0 -> 1.18.0_1

Installed packages to be REINSTALLED:
   bind-tools-9.18.19 (direct dependency changed: openssl111)
   cpdup-1.22 (direct dependency changed: openssl111)
   cyrus-sasl-2.1.28 (direct dependency changed: openssl111)
   cyrus-sasl-gssapi-2.1.28 (direct dependency changed: openssl111)
   ddclient-devel-3.10.0_7 (direct dependency changed: perl5)
   gmp-6.3.0 (option added: INFO)
   hostapd-2.10_8 (direct dependency changed: openssl111)
   isc-dhcp44-server-4.4.3P1 (direct dependency changed: openssl111)
   krb5-1.21.2 (direct dependency changed: openssl111)
   ldns-1.8.3 (direct dependency changed: openssl111)
   libevent-2.1.12 (direct dependency changed: openssl111)
   libfido2-1.13.0 (direct dependency changed: openssl111)
   monit-5.33.0 (direct dependency changed: openssl111)
   ntp-4.2.8p17_1 (direct dependency changed: openssl111)
   openldap26-client-2.6.6 (direct dependency changed: openssl111)
   openssh-portable-9.3.p2_1,1 (direct dependency changed: openssl111)
   openvpn-2.6.6 (direct dependency changed: openssl111)
   p5-Data-Validate-IP-0.27 (direct dependency changed: perl5)
   p5-IO-Socket-IP-0.42 (direct dependency changed: perl5)
   p5-IO-Socket-SSL-2.083_1 (direct dependency changed: perl5)
   p5-Mozilla-CA-20230821 (direct dependency changed: perl5)
   p5-Net-SSLeay-1.92 (direct dependency changed: openssl111)
   p5-NetAddr-IP-4.079 (direct dependency changed: perl5)
   php82-8.2.11 (direct dependency changed: openssl111)
   pkcs11-helper-1.29.0 (direct dependency changed: openssl111)
   py39-aioquic-0.9.21 (direct dependency changed: openssl111)
   py39-cryptography-41.0.4,1 (direct dependency changed: openssl111)
   python39-3.9.18 (direct dependency changed: openssl111)
   rrdtool-1.8.0_2 (direct dependency changed: perl5)
   socat-1.7.4.4 (direct dependency changed: openssl111)
   squid-5.9 (direct dependency changed: openssl111)
   strongswan-5.9.11_2 (direct dependency changed: openssl111)
   syslog-ng-4.4.0 (direct dependency changed: openssl111)
   wpa_supplicant-2.10_9 (direct dependency changed: openssl111)

Number of packages to be removed: 3
Number of packages to be installed: 1
Number of packages to be upgraded: 18
Number of packages to be reinstalled: 34

The operation will free 22 MiB.
pkg-static: Cannot delete vital package: opnsense-devel!
pkg-static: If you are sure you want to remove opnsense-devel,
pkg-static: unset the 'vital' flag with: pkg set -v 0 opnsense-devel
Starting web GUI...done.
Generating RRD graphs...done.
***DONE***

PowerD enabled in the GUI (Settings->Miscellaneous) with Adaptive and HiAdaptive should in theory not lock the CPU, it hasn't in my experience.

How are you checking the frequency, using either sysctl hw.clockrate or sysctl dev.cpu.0.freq?

I wish we could see this in the GUI, like pfsense.

The command powerd -v shows realtime tracking of the freq.

Hi, Are you using the opnsense Firewall->Shaper at all?

If you aren't do you have some VPN running on opnsense or somewhere that some of the traffic is being proxied via, causing the bandwidth discrepencies?

Cheers
S.

Hi, just a quick warning that if anyone upgrades to the development version of opnsense which is currently OPNsense 24.1.a_205-amd64 and uses a non standard theme you will get GUI navigation issues, some formatting anomolies and dropdown boxes won't function with the mouse, entries aren't shown.

As a workaround I managed to navigate to System->General and use the keyboard to select opnsense under theme, was previously on cicada, which I prefer, being a dark theme. On Save the GUI then displays the fields correctly and dropdowns function as you would expect.

[My Version]
OPNsense 24.1.a_205-amd64
FreeBSD 13.2-RELEASE-p3
OpenSSL 1.1.1v 1 Aug 2023

Cheers
S.

Do I need to raise some formal bug request on this one, just wondered what the next steps would be?

I do think this ether dispatch scenario is related to me enabling RSS via that tuneable, need to validate that.

Previously I've used dispatch of deferred as that is a general recommendation for PPPoE connections (although others say to always use direct for a router) and I'm pretty sure that did distribute the traffic evenly over all 4 cores.

I'm not really sure whether having RSS tuning enabled will benefit me or not to be honest.

I do a lot of GeForce Now cloud gaming while my son is an avid PS5 gamer, and I'd say in the above configuration everything seems to run pretty well. However I like to tinker and get the best performance possible, and without having a specific lab to test this out at a more granular level, hard to say what is the best config I guess.

Also the iperf implementation is broken in opnsense, has been for a while now, raised a separate post on that one, so not easy for me to test the throughput side of things.

Hi,
As per subject, I've just noticed I have no ether dispatched traffic going via CPU1, not sure what's wrong, if indeed anything is wrong, just assumed all my 4 Cores would be somewhat balanced, see key config and netstat results below, any ideas?

I should mention I've tried changing the dispatch policy to direct, hybrid and deferred and makes no difference.

[Key Config/Info]
OPNsense 24.1.a_38-amd64
FreeBSD 13.2-RELEASE-p2
OpenSSL 1.1.1v 1 Aug 2023
WAN is PPPOE
machdep.hyperthreading_allowed=0
net.isr.dispatch=hybrid
net.inet.rss.bits=2
net.inet.rss.enabled=1
dev.igb.0.iflib.override_nrxds=1024 (I use 1024, rather that 2048 as supposed to improve low latency for gaming, that's more important than throughput in my house)   
dev.igb.0.iflib.override_nrxqs=2 (Note have amended down to 2 from 4 as I think that's the max for my nic)
dev.igb.0.iflib.override_ntxds=1024 (I use 1024, rather that 2048 as supposed to improve low latency for gaming, that's more important than throughput in my house)
dev.igb.0.iflib.override_ntxqs=2 (Note have amended down to 2 from 4 as I think that's the max for my nic)   
dev.igb.0.iflib.override_qs_enable=1   
dev.igb.0.iflib.rx_budget=65535   
dev.igb.1.iflib.override_nrxds=1024   
dev.igb.1.iflib.override_nrxqs=2 (Note have amended down to 2 from 4 as I think that's the max for my nic)   
dev.igb.1.iflib.override_ntxds=1024   
dev.igb.1.iflib.override_ntxqs=2  (Note have amended down to 2 from 4 as I think that's the max for my nic)   
dev.igb.1.iflib.override_qs_enable=1   
dev.igb.1.iflib.rx_budget=65535

[netstat -Q Output]
Configuration:
Setting                        Current        Limit
Thread count                         4            4
Default queue limit                256        10240
Dispatch policy                 hybrid          n/a
Threads bound to CPUs          enabled          n/a

Protocols:
Name   Proto QLimit Policy Dispatch Flags
ip         1   1000    cpu   hybrid   C--
igmp       2    256 source  default   ---
rtsock     3    256 source  default   ---
arp        4    256 source  default   ---
ether      5    256    cpu   direct   C--
ip6        6   1000    cpu   hybrid   C--
ip_direct     9    256    cpu   hybrid   C--
ip6_direct    10    256    cpu   hybrid   C--

Workstreams:
WSID CPU   Name     Len WMark   Disp'd  HDisp'd   QDrops   Queued  Handled
   0   0   ip         0   574        0 42253356        0 32874971 75128327
   0   0   igmp       0     0        0        0        0        0        0
   0   0   rtsock     0     5        0        0        0     9249     9249
   0   0   arp        0     0        0        0        0        0        0
   0   0   ether      0     0 413619592        0        0        0 413619592
   0   0   ip6        0   254        0  5024974        0  1157454  6182428
   0   0   ip_direct     0     0        0        0        0        0        0
   0   0   ip6_direct     0     0        0        0        0        0        0
   1   1   ip         0   197        0  1791065        0 112231187 114022252
   1   1   igmp       0     0        0        0        0        0        0
   1   1   rtsock     0     0        0        0        0        0        0
   1   1   arp        0     0        0        0        0        0        0
   1   1   ether      0     0        0        0        0        0        0
   1   1   ip6        0    96        0     2756        0  5212677  5215433
   1   1   ip_direct     0     0        0        0        0        0        0
   1   1   ip6_direct     0     0        0        0        0        0        0
   2   2   ip         0   182        0 22572352        0 64929554 87501906
   2   2   igmp       0     0        0        0        0        0        0
   2   2   rtsock     0     0        0        0        0        0        0
   2   2   arp        0     3        0   934187        0     3032   937219
   2   2   ether      0     0 42907359        0        0        0 42907359
   2   2   ip6        0   112        0  2200054        0  9231036 11431090
   2   2   ip_direct     0     0        0        0        0        0        0
   2   2   ip6_direct     0     0        0        0        0        0        0
   3   3   ip         0    85        0 17177460        0 243726123 260903583
   3   3   igmp       0     0        0        0        0        0        0
   3   3   rtsock     0     0        0        0        0        0        0
   3   3   arp        0     0        0        0        0        0        0
   3   3   ether      0     0 62508272        0        0        0 62508272
   3   3   ip6        0   115        0  1235672        0  4609712  5845384
   3   3   ip_direct     0     0        0        0        0        0        0
   3   3   ip6_direct     0     0        0        0        0        0        0

[Key Sysctl Information]
dev.igb.1.iflib.rxq1.cpu: 3
dev.igb.1.iflib.rxq0.cpu: 2
dev.igb.1.iflib.txq1.cpu: 3
dev.igb.1.iflib.txq0.cpu: 2
dev.igb.0.iflib.rxq1.cpu: 1
dev.igb.0.iflib.rxq0.cpu: 0
dev.igb.0.iflib.txq1.cpu: 1
dev.igb.0.iflib.txq0.cpu: 0

[Key dmesg output]
igb0: Using 2048 TX descriptors and 2048 RX descriptors
igb0: Using 2 RX queues 2 TX queues
igb0: Using MSI-X interrupts with 3 vectors
igb0: netmap queues/slots: TX 2/2048, RX 2/2048
igb1: Using 2048 TX descriptors and 2048 RX descriptors
igb1: Using 2 RX queues 2 TX queues
igb1: Using MSI-X interrupts with 3 vectors
igb1: netmap queues/slots: TX 2/2048, RX 2/2048

[vmstat -i ouput]
interrupt                          total       rate
irq6: uart4                            1          0
irq9: acpi0                          102          0
irq42: sdhci_pci0                     13          0
cpu0:timer                     386864295        995
cpu1:timer                      20699302         53
cpu2:timer                      27962835         72
cpu3:timer                      33559782         86
irq128: ahci0                    4333382         11
irq129: igb0:rxq0              181995425        468
irq130: igb0:rxq1               64331389        165
irq131: igb0:aq                        2          0
irq132: igb1:rxq0               65561270        169
irq133: igb1:rxq1              143084477        368
irq134: igb1:aq                        2          0
irq135: xhci0                         50          0
Total                          928392327       2388

Following on from above, after a manual reboot, the Gateway, Interfaces and Services all show just the VPN Client as down, updated pictures attached, so slightly better position.

To make the VPN Client Gateway green, I again just had to open that gateway, save and apply which brought it back.

However that really is a pointless exercise as I still need to kill the client VPN from remote console, and repeat the above exercise to get the Open VPN connection status to report back correctly.

root@OPNsense:~ # ps auxww | grep openvpn
root     3410   0.0  0.1  18068   7484  -  Ss   09:56    0:00.02 /usr/local/sbin/openvpn --config /var/etc/openvpn/client1.conf
root    75150   0.0  0.1  18068   7316  -  Ss   09:56    0:00.01 /usr/local/sbin/openvpn --config /var/etc/openvpn/server2.conf
root    85029   0.0  0.1  18068   7316  -  Ss   09:56    0:00.01 /usr/local/sbin/openvpn --config /var/etc/openvpn/server3.conf
root    67396   0.0  0.0  12720   2396  0  S+   10:08    0:00.00 grep openvpn
root@OPNsense:~ #

I killed 3410, which again shows vpn client gateway/interface/service as down.

Then started the VPN Client again, connected fine.

Only red now is on the Client Gateway again, so usual open it save and apply changes fixes it again.

Slightly better, but no cigar.

Hi Franco,
I've just upgraded to latest version and then rebooted:
OPNsense 23.7.r_54-amd64
FreeBSD 13.2-RELEASE-p1
OpenSSL 1.1.1u 30 May 2023

After reboot, some differences (listed below), have included screenshots for reference to show the initial startup position:

1. WAN PPPOE Gateway is now showing down, wasn't before. and Client VPN still showing offline
2. Interfaces is showing everything green, Client VPN is up and IP address assigned, so all good there now.
3. Services looking better, everything green apart from OpenVPN Client is Red.
4. Open VPN Connection status is showing VPN Client as failed, same as before
In addition to the interface, the process command shows it is running however:
root@OPNsense:~ # ps auxww | grep openvpn
root     8529   0.0  0.1  18068   7308  -  Ss   09:17    0:00.01 /usr/local/sbin/openvpn --config /var/etc/openvpn/server3.conf
root     9286   0.0  0.1  18068   7516  -  Ss   09:17    0:00.02 /usr/local/sbin/openvpn --config /var/etc/openvpn/client1.conf
root    99718   0.0  0.1  18068   7312  -  Ss   09:17    0:00.01 /usr/local/sbin/openvpn --config /var/etc/openvpn/server2.conf
root    41806   0.0  0.0  12720   2396  0  S+   09:32    0:00.00 grep openvpn
root@OPNsense:~ #

To manually fix this I then did the following:
1. To get both the PPPOE and Client VPN Gateways showing green, all I did was go into the Client VPN and save settings and apply, and it then immediately turned everything green. So that is better, but still should have been green from the start as everything is working.
2. To try and fix the openvpn connection status I first tried clicking restart, but showed as failed, this is because client is already running, so next went and killed it from the remote shell, which removed failed in connection status to blank. I also checked gateway and interface also then correctly showed client vpn as down and it did.
3. Next I started the client VPN and it connected.
4. Services are all green, Interfaces are all green, unfortunately VPN Client gateway is showing offline and 100% packet loss..
5. Went back into Gateways->Single and opened client vpn, clicked save and then apply changes and it went straight to green, no packet loss.

So still some work to do it seems to get to the bottom of this one. Hope this email helps track the issues down.

Just thought, I'm going to do another reboot, as previous reboot was forced by the upgrade, see if any difference, will update below.

Howdy! Yes, I do use IPV6 via BT Fiber in the UK, have WAN IPv6 Configuration Type set to DHCPv6 and LAN IPV6 set to Track Interface, works well.

Me switching on IPV6, may well have been the trigger to this issue.

I had thought this might have been a more common issue too.

With little forum discussion I did think maybe my config was corrupt in someway, so spent a while analyzing the XML export file, deleting everything from the GUI and then reimporting it, but as you can tell made diddly squat difference.

What is the best way for me to test the theory, should I just set the IPV6 sections to none in LAN and WAN and reboot?

I seem to remember on pfsense at least there was an IPV6 toggle for on or off, can't remember if I've seen that in opnsense?


Update on this, all I had to do was change the WAN IPV6 setting to some other IPv6 setting (not none) and this immediately breaks the GUI reporting on the client VPN, it shows it straight away as down, but it isn't really down. I then need to kill the client1.conf process from the gui to get it back up and running.

This was the previous forum post I mentioned in my above post, and that I used to help find the workaround:
https://forum.opnsense.org/index.php?topic=6376.msg27194#msg27194

Which resulted in this git bug issue being raised, but nothing ever addressed the fix it seems, If I am reading it correctly:
https://github.com/opnsense/core/issues/1931

OPNsense 23.7.r_35-amd64
FreeBSD 13.2-RELEASE-p1
OpenSSL 1.1.1u 30 May 2023

I've had a problem for a while, and it's one of the reasons I switched to the opnsense development version in hope it would fix it, but it hasn't, so maybe raising awareness here might get it on the radar of someone in the know.

I have seen one other post in the form, which I will try and dig out with the exact same issue a while back, but obviously didn't end up reaching a root cause and resolution, however it helped me find a manual fudge to get the GUI back aligned, that is until the next reboot.

[The Problem]
I have an OpenVPN Client which is always running on my opnsense router. It's set to Don't pull routes or add/remove routes automatically, I just use firewall rules to push traffic via it based on some specific ports and it works well.

Problem is after a reboot of the router, the GUI doesn't align to what is actually happening.

Firstly the Gateway is showing VPN Client is up
Secondly the Interfaces is showing the VPN Client is down, yet it has an IP allocated.
Thirdly the VPN Connection Status page is showing Client Type VPN with a Status of failed, and subsequent restarts fail too.

The VPN Log File has the following (snippet) which basically means it's already running in my eyes:
2023-07-24T17:30:56   Notice   openvpn_client1   Exiting due to fatal error   
2023-07-24T17:30:56   Error   openvpn_client1   Cannot open TUN/TAP dev /dev/tun1: Device busy (errno=16)   
2023-07-24T17:30:56   Notice   openvpn_client1   TUN/TAP device ovpnc1 exists previously, keep at

If I remote into the backend and run the following command it shows the client is indeed running:
root@OPNsense:~ # ps auxww | grep openvpn
root    47538   0.0  0.1  18068   7316  -  Ss   16:42     0:00.03 /usr/local/sbin/openvpn --config /var/etc/openvpn/server2.conf
root    56049   0.0  0.1  18068   7324  -  Ss   16:42     0:00.03 /usr/local/sbin/openvpn --config /var/etc/openvpn/server3.conf
root    65001   0.0  0.1  18068   7628  -  Ss   16:33     0:00.20 /usr/local/sbin/openvpn --config /var/etc/openvpn/client1.conf

So what I do next is to kill the client1 pid, 65001 in this instance

The gateway for the client VPN then goes to offline
The Interface still shows down but the IP Address disappears
The VPN Connection Status page is showing Client Type VPN with a Status of blank.

Next on the OpenVPN Connection status window I click the play button to start the VPN Client up.

It shows reconnecting initially and then after a refresh changes to connected and all other fields on the screen get populated. Logs all good too.

If I go back to Gateways it still shows VPN Client as offline
If I look at Interfaces it shows it's up and IP Address assigned.

Last step is I now go into the VPN Client Gateway->single, open up the vpn client gateway to edit it, just click save, then apply changes and that brings the gateway online and everything is finally green.

It's a complete faff, and I really hope this issue can get some development time to fix it. It used to work many many many months ago I think, but some update I assume broke it.

Happy to help diagnose this further if you need more information from me.

Thanks

Hi,
I've been getting this crash report error ever consistently since I switched to the development version, any ideas how to fix:

System Information:
User-Agent Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/114.0.0.0 Safari/537.36
FreeBSD 13.2-RELEASE-p1 stable/23.7-n254734-db656ecc44c SMP amd64
OPNsense 23.7.r_14 e2630a954
Plugins os-acme-client-3.18 os-ddclient-1.13_2 os-dmidecode-1.1_1 os-theme-cicada-1.34
Time Fri, 21 Jul 2023 10:07:06 +0100
OpenSSL 1.1.1u  30 May 2023
Python 3.9.17
PHP 8.2.8
PHP Errors:
[21-Jul-2023 09:00:04 Europe/London] Error: Call to undefined function legacy_interfaces_details() in /usr/local/etc/inc/plugins.inc.d/dpinger.inc:140
Stack trace:
#0 /usr/local/etc/inc/plugins.inc.d/dpinger.inc(351): dpinger_instances()
#1 /usr/local/etc/inc/plugins.inc(330): dpinger_status()
#2 /usr/local/etc/inc/legacy_bindings.inc(172): plugins_run('return_gateways...')
#3 /usr/local/opnsense/scripts/OPNsense/Monit/gateway_alert(52): return_gateways_status()
#4 {main}