False alarm, it seems my dyndns was acting up and giving out the wrong IP.

Yes, reboot is a great help for Pfsense, indeed.

I have a similar issue where my packages weren't installed. And of course I can't remember which packages I had. Is there a way to restart the upgrade process and get packages in?

I just finished the update and it works (or not depending on the point of view  ;) )

Connecting... Sending Client Hello... Waiting for Server Hello... ... received message: type = 22, ver = 0302, length = 58 ... received message: type = 22, ver = 0302, length = 2331 ... received message: type = 22, ver = 0302, length = 525 ... received message: type = 22, ver = 0302, length = 4 Sending heartbeat request... Unexpected EOF receiving record header - server closed connection No heartbeat response received, server likely not vulnerable

as it should be

Again thanks for the fast fix and happy 2.1.2

tobi

Unless that gender changer is actually a null modem adapter, then the cable is likely not correct.

Just wanted to add that I have the exact same problem both upgrading from 2.1 and also with a fresh 2.1.1 install. I have had a lot of trouble with 2.1.1 and this is one of them, so I was forced to revert back to 2.1 again.

If your system works fine after upgrade and you are sure that all packages have been installed properly, then this is just a package lock. Go to Diagnostics: Backup/restore and click Clear Package Lock button.

Thanks,  downloading new black lists fixed the problem! :)

After upgrading to 2.1.1 I tried to restore the backup I did just before the upgrade because the installed packages didn't survive the upgrade. When attempting to restore I get an error message about the SHA256 values not agreeing although the two values shown are identical. The first value is followed by a <> however. The encrypted, and correctly decrypted, config file is shown.

Snort is back.  I was able to successfully install the package today and it picked up previous settings and is working correctly.

Please mark as Solved. :)

Thanks guys, appreciate the info.

Just to add, I reduced the available cores in the BIOS from 8 to 4 and the MBUF utilization went from 100% to 50%.

All done - just needed to change interfaces using serial and now all working well - and MUCH faster than the old Alix.  No actual measurement of speed - but seems much more responsive.

Only strange thing - 9600 gave garbage, 38400 gave garbage, 115200 worked perfectly - watched all boios boot, then pfs starting, changed interface - loaded into pfs opening menu - all working fine.  Can't understand why 115200 - the backup config loaded from old Alix was 9600.

Presume (?) that APU-1C must run at 115200 by default?

In any case this might help someone with similar problem - although I still think it should have been 9600!

Thanks for suggestions.

Hi,

I had this exact issue recently.

My fix was removing the HDD and placing it in another box and then installing.

Once installed I moved the HDD back.

It's an issue with the installer and certain motherboards I think.

Regards,

Those logs are normal when using anything with dummynet (limiters, captive portal), so that's unrelated. Any other logs might be telling.

My understanding from quickly glancing over the forums is there are multiple OpenSSL binaries in pfSense and the main OS OpenSSL wasn't vulnerable to begin with, but the one that pfSense bundles (used by webgui, vpn, etc)  is. And to make matters more confusing packages themsevles may bundle their own versions of OpenSSL. So I think at best your process won't fix anything and at worse could require a reinstall.