pfSense

A quick suggestion for the routine which starts re-installing packages after the first reboot following the update:
- there should be a test/check of connectivity with pfsense packages servers before trying to download anything.
- test should be able to pass through the preconfigured proxy if that's the case, so pinging the server would not be appropriate. Perhaps downloading a dummy/test-file from the server(s) would assume that there is a connection available to packages servers
- If no connection is available, print something useful to the user, and continue booting normally
- also put something on the TTY console and the Web Dashboard, that package re-installation didn't succeed - and let the user the chance to trigger package reinstall later, when connection is made available.

Disabling the 'automatic dashboard auto-update check' at /system_update_settings.php seems to mitigate the issue for now.

Which widgets are enabled on you dashboard?

Steve Beaver wrote:

Which widgets are enabled on you dashboard?

- System Information
- Interfaces
- Firewall Logs
- Snort Alerts

this fixed my issue on 2.3, thanks

hello,
I've experienced a similar issue.

pfSense 2.3.1_5
IPv6 tunnel configured

pfSense in GUI was checking for updates and was resolving pkg.pfsense.org as IPv6 address (AAAA record) and couldn't check for updates.
This caused issues and 100% cpu for pkg process.

Checking " System > Advanced on the Networking tab > Prefer IPv4 over IPv6" was a good workaround, but this indicates that there's still that 100% cpu bug when pkg.pfsense.org is not responding correctly...right?

can you have a look in it?
or maybe fix IPv6 answering of pkg.pfsense.org :)

Nicola Bressan wrote:

I've experienced a similar issue.

can you have a look in it?
or maybe fix IPv6 answering of pkg.pfsense.org :)

IPv6 works just fine on pkg.pfsense.org. You're not hitting the issue here, please start a forum thread to discuss.

Chris Buechler wrote:

IPv6 works just fine on pkg.pfsense.org. You're not hitting the issue here, please start a forum thread to discuss.

ok I'll do it, but the fact that with IPv6 preference enabled, package update was not working correctly it's a matter of fact.

When I don't enable "Prefer to use IPv4 even if IPv6 is available" I get 100% CPU usage for pkg search:

2.3.1-RELEASE][root@pfSense.nbr.local]/root: ps aux | grep pkg
root    31701 93.0  1.8  45172  8980  -  R     2:26PM    0:44.03 /usr/sbin/pkg search --raw-format json-compact pfSense-base
root     7399  0.0  6.7 225160 32624  -  S     9:19PM    0:39.61 /usr/local/bin/php -f /usr/local/pkg/pfblockerng/pfblockerng.inc dnsbl
root    31683  0.0  1.6  45172  7624  -  I     2:26PM    0:00.01 /usr/sbin/pkg search --raw-format json-compact pfSense-base

last pid: 19104;  load averages:  0.91,  0.48,  0.25                                                                                  up 0+17:10:31  14:28:17
47 processes:  4 running, 43 sleeping
CPU: 68.2% user,  0.0% nice, 31.8% system,  0.0% interrupt,  0.0% idle
Mem: 19M Active, 127M Inact, 103M Wired, 38M Buf, 214M Free
Swap: 1024M Total, 1024M Free

  PID USERNAME    THR PRI NICE   SIZE    RES STATE    TIME    WCPU COMMAND
31701 root          1 102    0 45172K  8980K RUN      2:00 100.00% pkg
35155 unbound       1  20    0 38604K 13856K kqread   0:42   0.00% unbound

This is what's happening:

with IPv6 [before hitting Google to show it's working...]

[2.3.1-RELEASE][root@pfSense.nbr.local]/root: fetch -v -6 https://www.google.it
looking up www.google.it
connecting to www.google.it:443
SSL options: 83004bff
Peer verification enabled
Using CA cert file: /usr/local/etc/ssl/cert.pem
Verify hostname
TLSv1.2 connection established using ECDHE-ECDSA-AES128-GCM-SHA256
Certificate subject: /C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.google.com
Certificate issuer: /C=US/O=Google Inc/CN=Google Internet Authority G2
requesting https://www.google.it/
fetch: https://www.google.it: size of remote file is not known
www.google.it                                           10 kB  863 kBps 00m00s

[2.3.1-RELEASE][root@pfSense.nbr.local]/root: fetch -v -6 https://pkg.pfsense.org/pfSense_v2_3_1_amd64-core/meta.txz
looking up pkg.pfsense.org
connecting to pkg.pfsense.org:443
SSL options: 83004bff
Peer verification enabled
Using CA cert file: /usr/local/etc/ssl/cert.pem

over IPv4 it works:

[2.3.1-RELEASE][root@pfSense.nbr.local]/root: fetch -v -4 https://pkg.pfsense.org/pfSense_v2_3_1_amd64-core/meta.txz
looking up pkg.pfsense.org
connecting to pkg.pfsense.org:443
SSL options: 83004bff
Peer verification enabled
Using CA cert file: /usr/local/etc/ssl/cert.pem
Verify hostname
TLSv1.2 connection established using ECDHE-RSA-AES256-GCM-SHA384
Certificate subject: /OU=Domain Control Validated/OU=PositiveSSL Wildcard/CN=*.pfsense.org
Certificate issuer: /C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA
requesting https://pkg.pfsense.org/pfSense_v2_3_1_amd64-core/meta.txz
remote size / mtime: 944 / 1466102812
meta.txz                                      100% of  944  B 2265 kBps 00m00s
[2.3.1-RELEASE][root@pfSense.nbr.local]/root:

the problem that arises is always the same...when pkg update/fetching is not getting done correctly, the GUI hang with 100% cpu power being collected by the pkg process.

edit

edit.

I can just say I have the same bug with 2.3.2 version. Forcing Ipv4 as indicated in comment 13 worked around this bug.