pfSense Plus 26.03 Release Now Available!
-
Hmm, as I read this it looks like more of a warning than anything else. It comes from this: https://redmine.pfsense.org/issues/16658
-
@stephenw10 Yes, it seems so.
However, each time it reboots we don't need a false alarm, do we?
The right thing would be to check interface mtu/mss and vpn with dco custom mtu/mss and omit the warning.
And while we are at it, there is also confusion in certain post if mss is specified IS the value displayed, NOT the mss displayed minus 40 bytes.
This comes from the fact that when you don't enter mss in most cases (but not always, eg wireguard, openvpn dco to name a few) one has to specify the mss.
and THEN mss MUST be MTU -40.
Perhaps adding a note right at the field would also help. -
-
I updated my second sg1100 shelf spare. Using what I learned from the other spare 1100 and the production 4200, I tried the following major steps:
- Disable (but don't remove) pfBlocker.
- Stop other optional packages and services, but don't remove.
- Sign out of GUI.
- Update with console option 13.
- Re-enable pfBlocker and update or reload the alias lists.
- Reboot once more. "It's the only way to be sure."
This update succeeded on the first try, and was an order or more of magnitude faster than updating from the GUI as I'd done with the first 1100 and the 4200. Instead of 45+ minutes to update via Starlink it took about 15 minutes or less.
I suspect running the GUI update profoundly slows the update process even on a faster box like the 4200.
-
said in pfSense Plus 26.03 Release Now Available!:
about 15 minutes or less.
Correction: FIVE minutes.
PS: Why can't we edit our posts on this forum?
-
'Messages from the team' has different permissions set than normal areas of the forum.
-
Updated 6100 without issues. Have applied two Fresports-tailscaled updates without issues; Tailscale-GUI Authorization and Advertised Routes have persisted after reboots.
-
@CarlMRoss said in pfSense Plus 26.03 Release Now Available!:
Updated 6100 without issues. Have applied two Fresports-tailscaled updates without issues; Tailscale-GUI Authorization and Advertised Routes have persisted after reboots.
Have you applied these freeports updates to tailscale because of issues with the tailscale client build in the current pfSense tailscale Package, or?
-
No. The 26.03 Tailscale Package had no issues. I have updated Tailscale from Freshports since version 24.11 because I prefer to keep all my Tailscale devices on the same version. I had to deal with compatibility issues until now.
-
I said in pfSense Plus 26.03 Release Now Available!:
Suricata: https://forum.netgate.com/post/1240644 (prevents Blocks page crash)
IMO, those running Suricata should also look for:
https://forum.netgate.com/post/1241305 -
For those running OpenVPN:
https://forum.netgate.com/topic/200658/openvpn-race-condition-remediation (CVE-2026-40215) -
@SteveITS From cli
root: pkg upgrade -y Updating pfSense-core repository catalogue... pkg: Failed to fetch https://pfsense-plus-pkg.netgate.com/pfSense_plus-v26_03_amd64-core/meta.conf: response code 400 pkg: Failed to fetch https://pfsense-plus-pkg.netgate.com/pfSense_plus-v26_03_amd64-core/meta.txz: response code 400 repository pfSense-core has no meta file, using default settings pkg: Failed to fetch https://pfsense-plus-pkg.netgate.com/pfSense_plus-v26_03_amd64-core/data.pkg: response code 400 pkg: Failed to fetch https://pfsense-plus-pkg.netgate.com/pfSense_plus-v26_03_amd64-core/data.tzst: response code 400 pkg: Failed to fetch https://pfsense-plus-pkg.netgate.com/pfSense_plus-v26_03_amd64-core/packagesite.pkg: response code 400 pkg: Failed to fetch https://pfsense-plus-pkg.netgate.com/pfSense_plus-v26_03_amd64-core/packagesite.tzst: response code 400 Unable to update repository pfSense-core Updating pfSense repository catalogue... pkg: Failed to fetch https://pfsense-plus-pkg.netgate.com/pfSense_plus-v26_03_amd64-pfSense_plus_v26_03/meta.conf: response code 400 pkg: Failed to fetch https://pfsense-plus-pkg.netgate.com/pfSense_plus-v26_03_amd64-pfSense_plus_v26_03/meta.txz: response code 400 repository pfSense has no meta file, using default settings pkg: Failed to fetch https://pfsense-plus-pkg.netgate.com/pfSense_plus-v26_03_amd64-pfSense_plus_v26_03/data.pkg: response code 400 pkg: Failed to fetch https://pfsense-plus-pkg.netgate.com/pfSense_plus-v26_03_amd64-pfSense_plus_v26_03/data.tzst: response code 400 pkg: Failed to fetch https://pfsense-plus-pkg.netgate.com/pfSense_plus-v26_03_amd64-pfSense_plus_v26_03/packagesite.pkg: response code 400 pkg: Failed to fetch https://pfsense-plus-pkg.netgate.com/pfSense_plus-v26_03_amd64-pfSense_plus_v26_03/packagesite.tzst: response code 400 Unable to update repository pfSense Error updating repositories!Only after checking for upgrade from web ui
it upgrades correctly
The following 2 package(s) will be affected (of 0 checked): Installed packages to be UPGRADED: openvpn: 2.6.16 -> 2.6.20 [pfSense] pfSense-repoc: 20260205.051513 -> 20260508.234816 [pfSense] Number of packages to be upgraded: 2 10 MiB to be downloaded. [1/2] Fetching openvpn-2.6.20: 100% 492 KiB 503.5 k/s 00:01 [2/2] Fetching pfSense-repoc-20260508.234816: 100% 9 MiB 9.9 M/s 00:01 Checking integrity... done (0 conflicting) [1/2] Upgrading openvpn from 2.6.16 to 2.6.20... ===> Creating groups Using existing group 'openvpn' ===> Creating users Using existing user 'openvpn' [1/2] Extracting openvpn-2.6.20: 100% [2/2] Upgrading pfSense-repoc from 20260205.051513 to 20260508.234816... [2/2] Extracting pfSense-repoc-20260508.234816: 100% ===== )However on another instance, after touching web upgrade (otherwise it gets the same 400 error)
I see it upgrades more packets
I'm sure everything was up to date toopkg upgrade -y Updating pfSense-core repository catalogue... pfSense-core repository is up to date. Updating pfSense repository catalogue... pfSense repository is up to date. All repositories are up to date. Checking for upgrades (218 candidates): 100% Processing candidates (218 candidates): 100% The following 6 package(s) will be affected (of 0 checked): Installed packages to be UPGRADED: pfSense-repoc: 20260205.051513 -> 20260508.234816 [pfSense] Installed packages to be REINSTALLED: pfSense-base-26.03 [pfSense-core] (Vital flag changed: 'true' -> 'false') pfSense-boot-26.03 [pfSense-core] (Vital flag changed: 'true' -> 'false') pfSense-kernel-pfSense-26.03 [pfSense-core] (Vital flag changed: 'true' -> 'false') pfSense-upgrade-1.3.25 [pfSense] (Vital flag changed: 'true' -> 'false') php85-8.5.2 [pfSense] (Vital flag changed: 'true' -> 'false') Number of packages to be upgraded: 1 Number of packages to be reinstalled: 5 170 MiB to be downloaded. [1/6] Fetching pfSense-base-26.03: 100% 111 MiB 1.7 M/s 01:10 [2/6] Fetching php85-8.5.2: 100% 16 MiB 1.4 M/s 00:12 [3/6] Fetching pfSense-boot-26.03: 100% 3 MiB 710.1 k/s 00:05 [4/6] Fetching pfSense-kernel-pfSense-26.03: 100% 30 MiB 2.4 M/s 00:13 [5/6] Fetching pfSense-upgrade-1.3.25: 100% 31 KiB 32.2 k/s 00:01 [6/6] Fetching pfSense-repoc-20260508.234816: 100% 9 MiB 1.4 M/s 00:07 Checking integrity... done (0 conflicting) [1/6] Reinstalling pfSense-base-26.03... [1/6] Extracting pfSense-base-26.03: 100% ===> Keeping a copy of current version mtree ===> Removing schg flag from base files ===> Extracting new base tarball ===> Removing static obsoleted files [2/6] Reinstalling pfSense-boot-26.03... [2/6] Extracting pfSense-boot-26.03: 100% [3/6] Reinstalling pfSense-kernel-pfSense-26.03... [3/6] Extracting pfSense-kernel-pfSense-26.03: 100% [4/6] Upgrading pfSense-repoc from 20260205.051513 to 20260508.234816... [4/6] Extracting pfSense-repoc-20260508.234816: 100% [5/6] Reinstalling pfSense-upgrade-1.3.25... [5/6] Extracting pfSense-upgrade-1.3.25: 100% [6/6] Reinstalling php85-8.5.2... [6/6] Extracting php85-8.5.2: 100%Why it upgraded 6 core packages then?
-
That 400 error at the CLI is expected if you haven't logged into the GUI for a while. It implies the client side cert has expired.
As an alternative you can run:
pfSense-repoc -N
That will pull a new cert like the webgui does when it checks for updates. -
does this version detect a NVME over mpcie on the 2100 and or the wifi adapter on that port? I was able to solve the Squid status page myself finally on 25 but I cant go past the version where the drivers for my Optane drive are deleted. . .
-
No that driver is still broken upstream.
-
Unbound being OOM-killed silently after upgrade to 26.03 — Netgate 2100
Hardware: Netgate 2100 (dual-core ARM Cortex-A53)
Software: pfSense Plus 26.03 (upgraded from 25.07.1 on April 21, 2026)
DNS Resolver: Unbound with DNS Query Forwarding and DoT enabled (forwarding to 1.1.1.1/1.0.0.1)
DHCP Backend: Kea
Symptom
Since upgrading to 26.03, Unbound intermittently stops running with no log entries — not even at verbosity level 3. Internet access is lost and requires either manually starting Unbound from the GUI or a full reboot to restore. A reboot provides extended stability (hours to days); manually restarting Unbound without rebooting sometimes results in a rapid recurrence.
This behavior did not occur on 25.07.1 with the same configuration.
Root Cause Identified: Kernel OOM Kill
Searching the rotated system log files revealed the following:
May 12 12:41:52 pfSense-small kernel: pid 57593 (unbound), jid 0, uid 59, was killed: failed to reclaim memoryUnbound is being killed by the kernel due to memory pressure. Because it receives SIGKILL, the process has no opportunity to write log entries before dying, which explains the complete silence in resolver.log regardless of verbosity level.
A second likely crash event was identified on May 1 via an anomalous kea2unbound entry in dhcpd.log:
May 1 21:31:24 kea2unbound[14963]: Include updated: /var/unbound/leases/leases4.conf May 1 21:31:24 kea2unbound[14963]: Synchronization completed: 42522.2561msNote the 42.5-second synchronization time (normal is 450–850ms) and the absence of the usual "Unbound fast reloaded" line between the two entries, indicating kea2unbound could not complete the reload — consistent with Unbound being dead or unresponsive at that time.
Memory State (post-reboot, from top)
Mem: 14M Active, 21M Inact, 198M Laundry, 2900M Wired, 187M Free ARC: 42M Total, 13M MFU, 18M MRU, 381K Anon, 474K Header, 8134K Other 9041K Compressed, 79M Uncompressed, 8.96:1 RatioThe 2900M of wired memory is notably high and may indicate a memory regression in 26.03. Memory appears adequate immediately after a reboot but Unbound is eventually OOM-killed as memory accumulates over time.
Additional Observations
- Suricata has been disabled for several months — resource contention is not a factor
- No cron jobs are configured (crontab is empty)
- The issue is reproducible and tied directly to the 26.03 upgrade — 25.07.1 boot environment is available and was stable
- Normal kea2unbound reload times: 450–850ms across all log history, with the single exception noted above
- The kea2unbound integration triggers an Unbound fast reload on each DHCP lease change; under memory pressure these reloads may be contributing to instability
Happy to provide additional diagnostics if helpful. Planning to roll back to 25.07.1 in the interim given the business-critical nature of this network.
-
What is using memory in that system? What does
top -HaSPshow? -
@stephenw10 - Please see below. Note: I have a CRON job collecting mem usage on unbound. Thanks and wanted to solicit consensus before crying wolf and submitting a bug since I couldn't find anything in redmine related to this circumstance. -Jon
[26.03-RELEASE][]/var/log: uptime 6:19AM up 10:37, 2 users, load averages: 0.41, 0.22, 0.21[26.03-RELEASE][]/var/log: top -HaSPn -o res all last pid: 82060; load averages: 0.13, 0.19, 0.21 up 0+10:33:08 06:15:39 338 threads: 3 running, 310 sleeping, 6 zombie, 19 waiting CPU 0: 2.0% user, 1.8% nice, 5.8% system, 1.0% interrupt, 89.2% idle CPU 1: 2.8% user, 2.5% nice, 4.5% system, 1.7% interrupt, 88.5% idle Mem: 74M Active, 251M Inact, 400M Wired, 2593M Free ARC: 37M Total, 9749K MFU, 21M MRU, 527K Anon, 383K Header, 4588K Other 6905K Compressed, 70M Uncompressed, 10.44:1 Ratio PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 85072 unbound 0 0 93M 69M kqread 1 2:17 0.24% /usr/local/sbin/unbound -c /var/unbound/unbound.conf{unbound} 85072 unbound 0 0 93M 69M kqread 1 1:53 0.15% /usr/local/sbin/unbound -c /var/unbound/unbound.conf{unbound} 91594 root 59 0 153M 56M accept 1 0:35 0.00% php-fpm: pool nginx (php-fpm){php-fpm} 83027 root 59 0 153M 56M accept 0 0:31 0.00% php-fpm: pool nginx (php-fpm){php-fpm} 27963 root 59 0 149M 55M accept 0 0:26 0.00% php-fpm: pool nginx (php-fpm) 66855 root 59 0 122M 51M accept 1 0:17 0.00% php-fpm: pool nginx (php-fpm){php-fpm} 73276 root 0 0 76M 51M piperd 0 0:06 0.00% /usr/local/bin/php_pfb -f /usr/local/pkg/pfblockerng/pfblockerng.inc filterlog 65988 root 59 0 122M 50M accept 1 0:22 0.00% php-fpm: pool nginx (php-fpm){php-fpm} 57395 root 19 0 118M 50M accept 0 0:33 0.00% php-fpm: pool nginx (php-fpm) 39992 root 15 0 118M 48M accept 1 0:48 0.00% php-fpm: pool nginx (php-fpm) 625 root 0 0 116M 34M kqread 1 0:02 0.00% php-fpm: master process (/usr/local/lib/php-fpm.conf) (php-fpm) 90328 root 0 0 50M 26M select 1 0:11 0.00% /usr/local/sbin/kea-dhcp4 -c /usr/local/etc/kea/kea-dhcp4.conf{kea-dhcp4} 90328 root 0 0 50M 26M uwait 0 0:05 0.00% /usr/local/sbin/kea-dhcp4 -c /usr/local/etc/kea/kea-dhcp4.conf{kea-dhcp4} 90328 root 0 0 50M 26M uwait 0 0:04 0.00% /usr/local/sbin/kea-dhcp4 -c /usr/local/etc/kea/kea-dhcp4.conf{kea-dhcp4} 90328 root 59 0 50M 26M uwait 0 0:00 0.00% /usr/local/sbin/kea-dhcp4 -c /usr/local/etc/kea/kea-dhcp4.conf{kea-dhcp4} 90328 root 59 0 50M 26M uwait 1 0:00 0.00% /usr/local/sbin/kea-dhcp4 -c /usr/local/etc/kea/kea-dhcp4.conf{kea-dhcp4} 90328 root 59 0 50M 26M uwait 0 0:00 0.00% /usr/local/sbin/kea-dhcp4 -c /usr/local/etc/kea/kea-dhcp4.conf{kea-dhcp4} 90328 root 59 0 50M 26M uwait 0 0:00 0.00% /usr/local/sbin/kea-dhcp4 -c /usr/local/etc/kea/kea-dhcp4.conf{kea-dhcp4} 90848 root 0 0 44M 24M select 1 0:05 0.00% /usr/local/sbin/kea-dhcp6 -c /usr/local/etc/kea/kea-dhcp6.conf{kea-dhcp6} 90848 root 0 0 44M 24M uwait 0 0:00 0.00% /usr/local/sbin/kea-dhcp6 -c /usr/local/etc/kea/kea-dhcp6.conf{kea-dhcp6} 90848 root 59 0 44M 24M uwait 0 0:00 0.00% /usr/local/sbin/kea-dhcp6 -c /usr/local/etc/kea/kea-dhcp6.conf{kea-dhcp6} 90848 root 0 0 44M 24M uwait 0 0:00 0.00% /usr/local/sbin/kea-dhcp6 -c /usr/local/etc/kea/kea-dhcp6.conf{kea-dhcp6} 90848 root 59 0 44M 24M uwait 0 0:00 0.00% /usr/local/sbin/kea-dhcp6 -c /usr/local/etc/kea/kea-dhcp6.conf{kea-dhcp6} 90848 root 59 0 44M 24M uwait 0 0:00 0.00% /usr/local/sbin/kea-dhcp6 -c /usr/local/etc/kea/kea-dhcp6.conf{kea-dhcp6} 90848 root 59 0 44M 24M uwait 0 0:00 0.00% /usr/local/sbin/kea-dhcp6 -c /usr/local/etc/kea/kea-dhcp6.conf{kea-dhcp6} 55299 root 0 0 35M 13M kqread 1 0:06 0.00% nginx: worker process (nginx) 55178 root 0 0 35M 13M kqread 0 0:01 0.00% nginx: worker process (nginx) 83234 root 7 0 23M 12M select 1 0:00 0.00% sshd-session: jonsmall [priv] (sshd-session) 54922 root 35 0 32M 11M sigsus 1 0:00 0.00% nginx: master process /usr/local/sbin/nginx -c /var/etc/nginx-webConfigurator.conf (nginx) 78668 root 0 0 23M 10M select 1 0:00 0.00% sshd: /usr/sbin/sshd [listener] 0 of 10-100 startups (sshd) 61013 root 0 0 20M 10M select 1 0:01 0.00% /usr/local/sbin/openvpn --config /var/etc/openvpn/server1/config.ovpn 54117 root 0 0 24M 9568K select 1 0:06 0.00% /usr/local/sbin/ntpd -g -c /var/etc/ntpd.conf -p /var/run/ntpd.pid{ntpd} 45867 root 0 0 21M 7140K bpf 0 0:01 0.00% /usr/local/bandwidthd/bandwidthd 46111 root 0 0 21M 7100K bpf 1 0:01 0.00% /usr/local/bandwidthd/bandwidthd 46422 root 0 0 21M 7100K bpf 0 0:01 0.00% /usr/local/bandwidthd/bandwidthd 46703 root 0 0 21M 6972K bpf 0 0:01 0.00% /usr/local/bandwidthd/bandwidthd 45580 root 0 0 21M 6888K bpf 0 0:01 0.00% /usr/local/bandwidthd/bandwidthd 47163 root 0 0 21M 6852K bpf 1 0:01 0.00% /usr/local/bandwidthd/bandwidthd 47331 root 0 0 21M 6852K bpf 0 0:01 0.00% /usr/local/bandwidthd/bandwidthd 47548 root 0 0 21M 6724K bpf 1 0:01 0.00% /usr/local/bandwidthd/bandwidthd 86589 root 0 0 15M 4348K piperd 1 0:00 0.00% /usr/local/libexec/sshg-parser 1776 root 0 0 14M 4316K wait 1 0:28 0.05% /sbin/devd -q -f /etc/pfSense-devd.conf 88682 root 59 0 15M 4256K select 1 0:00 0.00% sshg-parser: system.net (sshg-parser) 59675 avahi 0 0 14M 4228K select 1 0:36 0.00% avahi-daemon: running [pfSense-small.local] (avahi-daemon) 80315 root 0 0 30M 4060K usem 1 0:00 0.00% /usr/local/sbin/filterdns -p /var/run/filterdns.pid -i 300 -c /var/etc/filterdns.conf -d 1{resi4-srv.1-voip.co} 80315 root 0 0 30M 4060K usem 0 0:00 0.00% /usr/local/sbin/filterdns -p /var/run/filterdns.pid -i 300 -c /var/etc/filterdns.conf -d 1{home-pc.home.lan} 80315 root 0 0 30M 4060K usem 0 0:00 0.00% /usr/local/sbin/filterdns -p /var/run/filterdns.pid -i 300 -c /var/etc/filterdns.conf -d 1{merge-thread} 80315 root 59 0 30M 4060K usem 0 0:00 0.00% /usr/local/sbin/filterdns -p /var/run/filterdns.pid -i 300 -c /var/etc/filterdns.conf -d 1{filterdns} 80315 root 0 0 30M 4060K usem 1 0:00 0.00% /usr/local/sbin/filterdns -p /var/run/filterdns.pid -i 300 -c /var/etc/filterdns.conf -d 1{filterdns} 63732 root 0 0 14M 3872K bpf 1 0:33 0.00% /usr/local/sbin/filterlog -i pflog0 -p /var/run/filterlog.pid 74965 root 59 0 13M 3620K zio->i 0 0:00 0.00% /bin/sh /etc/rc.d/devmatch quietstart ? at bus=1 hubaddr=1 port=1 devaddr=2 interface=0 ugen=ugen1.2 vendor=0x0764 product=0x0501 devclass=0x00 devsubclass=0x00 devproto=0x00 sernum="" release=0x0001 mode=host intclass=0x03 intsubclass=0x00 intprotocol=0x00 on uhub0 39632 root 59 0 13M 3472K wait 0 0:00 0.00% -sh (sh) 92569 root 0 0 13M 3424K kqread 1 0:28 0.00% /usr/sbin/syslogd -O rfc3164 -s -c -c -l /var/dhcpd/var/run/log -P /var/run/syslog.pid -f /etc/syslog.conf 40788 root 59 0 13M 3324K ttyin 1 0:00 0.00% /bin/sh /etc/rc.initial 37869 root 59 20 13M 3240K wait 1 0:00 0.00% /bin/sh /etc/rc.update_pkg_metadata 38178 root 59 0 13M 3208K wait 1 0:00 0.00% login [pam] (login) 93516 root 0 0 13M 3204K select 0 0:00 0.00% syslogd: syslogd.casper (syslogd) 683 root 39 20 13M 3192K kqread 1 0:00 0.00% /usr/local/sbin/check_reload_status 86872 root 0 0 13M 3192K nanslp 1 0:00 0.00% /usr/local/libexec/sshg-blocker{sshg-blocker} 86872 root 59 0 13M 3192K piperd 1 0:00 0.00% /usr/local/libexec/sshg-blocker{sshg-blocker} 55474 _dhcp 0 0 13M 3192K select 1 0:00 0.00% dhclient: mvneta0 (dhclient) 85935 root 59 0 13M 3152K wait 1 0:00 0.00% /bin/sh /usr/local/sbin/sshguard -i /var/run/sshguard.pid 88453 root 59 20 13M 3148K wait 0 0:29 0.00% /bin/sh /var/db/rrd/updaterrd.sh 87165 root 59 0 13M 3148K wait 0 0:00 0.00% /bin/sh /usr/local/sbin/sshguard -i /var/run/sshguard.pid 88476 root 59 0 13M 3144K piperd 1 0:00 0.00% /bin/sh /usr/local/libexec/sshg-fw-pf 88355 root 59 0 13M 3144K select 1 0:00 0.00% sshg-blocker: system.net (sshg-blocker) 94645 root 59 0 13M 3128K select 1 0:00 0.00% syslogd: system.net (syslogd) 37179 root -10 0 13M 3036K select 1 0:01 0.00% dhclient: mvneta0 [priv] (dhclient) 51817 root 0 0 14M 3000K nanslp 0 0:10 0.00% /usr/local/bin/dpinger -S -r 0 -i WAN_DHCP -B 100.64.80.159 -p /var/run/dpinger_WAN_DHCP~100.64.80.159~100.64.0.1.pid -u /var/run/dpinger_WAN_DHCP~100.64.80.159~100.64.0.1.sock -d 1 -s 500 -l 2000 -t 60000 -A 1000 -D 500 -L 20 100.64.0.1{dpinger} 51817 root 0 0 14M 3000K sbwait 0 0:03 0.00% /usr/local/bin/dpinger -S -r 0 -i WAN_DHCP -B 100.64.80.159 -p /var/run/dpinger_WAN_DHCP~100.64.80.159~100.64.0.1.pid -u /var/run/dpinger_WAN_DHCP~100.64.80.159~100.64.0.1.sock -d 1 -s 500 -l 2000 -t 60000 -A 1000 -D 500 -L 20 100.64.0.1{dpinger} 51817 root 0 0 14M 3000K nanslp 0 0:01 0.00% /usr/local/bin/dpinger -S -r 0 -i WAN_DHCP -B 100.64.80.159 -p /var/run/dpinger_WAN_DHCP~100.64.80.159~100.64.0.1.pid -u /var/run/dpinger_WAN_DHCP~100.64.80.159~100.64.0.1.sock -d 1 -s 500 -l 2000 -t 60000 -A 1000 -D 500 -L 20 100.64.0.1{dpinger} 51817 root 0 0 14M 3000K accept 1 0:00 0.00% /usr/local/bin/dpinger -S -r 0 -i WAN_DHCP -B 100.64.80.159 -p /var/run/dpinger_WAN_DHCP~100.64.80.159~100.64.0.1.pid -u /var/run/dpinger_WAN_DHCP~100.64.80.159~100.64.0.1.sock -d 1 -s 500 -l 2000 -t 60000 -A 1000 -D 500 -L 20 100.64.0.1{dpinger} 51817 root 59 0 14M 3000K uwait 1 0:00 0.00% /usr/local/bin/dpinger -S -r 0 -i WAN_DHCP -B 100.64.80.159 -p /var/run/dpinger_WAN_DHCP~100.64.80.159~100.64.0.1.pid -u /var/run/dpinger_WAN_DHCP~100.64.80.159~100.64.0.1.sock -d 1 -s 500 -l 2000 -t 60000 -A 1000 -D 500 -L 20 100.64.0.1{dpinger} 35936 root 0 0 13M 2960K select 1 0:00 0.00% dhclient: system.syslog (dhclient) 684 root 59 20 13M 2956K kqread 0 0:00 0.00% check_reload_status: Monitoring daemon of check_reload_status (check_reload_status) 73029 root 0 0 13M 2932K kqread 1 0:24 0.00% /usr/bin/tail_pfb -n0 -F /var/log/filter.log 94724 root 59 0 13M 2860K nanslp 1 0:02 0.00% /usr/sbin/cron -s 86247 root 0 0 13M 2808K kqread 0 0:12 0.00% tail -F -n 0 /var/log/auth.log 74316 root 0 0 13M 2780K select 0 0:18 0.00% tail_pfb: system.fileargs (tail_pfb) 91417 root 0 0 13M 2780K select 0 0:10 0.00% tail: system.fileargs (tail) 66777 root 0 0 13M 2728K select 0 0:00 0.00% /usr/local/sbin/radvd -p /var/run/radvd.pid -C /var/etc/radvd.conf -m syslog 85846 root 59 0 13M 2552K kqread 1 0:00 0.00% daemon: sshguard[85935] (daemon) 22449 root 59 0 13M 2488K nanslp 0 0:00 0.00% minicron: helper /usr/local/sbin/fcgicli -f /etc/rc.update_alias_url_data (minicron) 20447 root 0 0 13M 2484K nanslp 0 0:00 0.00% minicron: helper /usr/local/bin/ping_hosts.sh (minicron) 21593 root 0 0 13M 2484K nanslp 0 0:00 0.00% minicron: helper /usr/local/sbin/fcgicli -f /etc/rc.expireaccounts (minicron) 21162 root 35 0 13M 2480K nanslp 0 0:00 0.00% minicron: helper /usr/local/bin/ipsec_keepalive.php (minicron) 21920 root 59 0 13M 2480K wait 1 0:00 0.00% /usr/local/bin/minicron 86400 /var/run/update_alias_url_data.pid /usr/local/sbin/fcgicli -f /etc/rc.update_alias_url_data 19823 root 59 0 13M 2480K wait 1 0:00 0.00% /usr/local/bin/minicron 240 /var/run/ping_hosts.pid /usr/local/bin/ping_hosts.sh 20851 root 59 0 13M 2476K wait 0 0:00 0.00% /usr/local/bin/minicron 300 /var/run/ipsec_keepalive.pid /usr/local/bin/ipsec_keepalive.php 21334 root 59 0 13M 2476K wait 0 0:00 0.00% /usr/local/bin/minicron 3600 /var/run/expire_accounts.pid /usr/local/sbin/fcgicli -f /etc/rc.expireaccounts 37875 root 59 20 13M 2428K nanslp 0 0:00 0.00% sleep 35917 31537 root 59 20 13M 2420K nanslp 1 0:00 0.00% sleep 60 <truncated> -
@johan333 Do you have pfBlocker set to Python mode?
-
That ^
Also 69M doesn't seem especially high. I assume it increases significantly since it's only been up for 10h.
