@doktornotor: [image: 335081ba60.jpg] +1 My bet is your subnet is /24..  Right?

Does it stuck after Prompt: OK? You can't type anything and no other error message?

Nice one  8)

@doktornotor: Well, if you want RAID with 2.3.x, use can use gmirror. I missed that option entirely… Now the box is deployed so it's too late to fix. I'll just have to rely on the drive until 2.4 comes out  :)

Did another round of updates this morning. D2500 Atom w/ AMD64 build had no issues. Remaining 3 systems were all D525 i386 builds and all had the issue. All were 2.3.3 to 2.3.3 p1 upgrades through gui. Update: Confirmed occured on AMD 64 Intel Atom D525.

FYI, I don't think 2.3.3-p1 was announced on the email announcement list.

Another piece of info, from the gateway log. This is what is in the log for the most recent incident, they are all the same: Mar 13 14:24:03 dpinger GW_WAN 216.177.49.1: Alarm latency 1595us stddev 1087us loss 22% Mar 13 14:29:22 dpinger GW_WAN 216.177.49.1: sendto error: 50 Mar 13 14:29:22 dpinger GW_WAN 216.177.49.1: sendto error: 50 Mar 13 14:29:23 dpinger GW_WAN 216.177.49.1: sendto error: 50 Mar 13 14:29:23 dpinger GW_WAN 216.177.49.1: sendto error: 50 Mar 13 14:30:22 dpinger GW_WAN 216.177.49.1: Clear latency 2014us stddev 2139us loss 6%

I have an ALIX running 2.3.3-p1 and it still chugs along. It's not perfect, but it runs. The hardware was great for its time, but it's past EOL. If it still operates, keep using it. We intend to support 2.3.x for a year or so after 2.4 releases. You're welcome to keep running 2.3.x as long as you want on there. NanoBSD upgrades have always worked fine in our testing, and from our customers that have reported issues, most of them were due to faulty CF and the others were connectivity related or in very rare cases, a configuration issue preventing DNS from working during the upgrade. Even new cards can be faulty, it's the luck of the draw there. We can't fix or code around broken disks. Sandisk is usually reliable and fast, at least the 200X ones I typically use. You have to pay a little more for them but they are worth it: SanDisk SDCFH-004G. But even the best CF is still CF.

Without knowing what it's saying on the console, it's impossible to speculate. 2.3.3 to 2.3.3-p1 is a very, very small update. It is highly unlikely it would be the cause of a connectivity problem.

I don't use Windows so I'm guessing that the Kasperky software is intercepting your https connection and it doesn't like the self signed certificate issued by the pfSense software. Try temporarily deactivating your Kaspersky software to see if you get a browser error that you need to create an exception for the pfSense software self signed certificate. It may work OK with Kasperky after you create the exception.

@pfBasic: Try this: https://forum.pfsense.org/index.php?topic=117469.0 Ahh Thanx I just did this (booting from the ssd) Check if enabled (ssh to pfSense, and select the shell) /sbin/tunefs -p / To enable 1: Boot in singleuser mode (use console) 2: do a df , to get the disk uuid 3: Enter (adapt to your uuid) - /sbin/tunefs -t enable /dev/ufsid/ <uuid from="" df="">4: reboot Check if enabled /sbin/tunefs -p /</uuid> /Bingo

Good, so I am not going crazy. The usual process is that the system reboots and during the boot various code is unpacked - so the install is done in practice at that time. I would have thought that version.patch would get put into place at that time, along with other stuff to be added/updated in /etc, and thus would be visible in /etc in its proper upgraded state. But I guess somehow version.patch is in some component pkg that only "does its thing" on the 2nd boot. Renato is likely to know the detail of all that process straight off the top of his head.

I run into the same problem, in my case it was a bad link for the pkg cache. This is how I fix it: # unlink /root/var/cache/pkg # mkdir /root/var/cache/pkg

Here is the current result of running``` pkg info -x pfSense pfSense-2.3.3_1 pfSense-Status_Monitoring-1.6.1_3 pfSense-base-2.3.3_1 pfSense-default-config-2.3.3_1 pfSense-kernel-pfSense-2.3.3_1 pfSense-pkg-AutoConfigBackup-1.47 pfSense-pkg-Avahi-1.11_2 pfSense-pkg-openvpn-client-export-1.4.1 pfSense-rc-2.3.3_1 pfSense-repo-2.3.3 pfSense-upgrade-0.20 php56-pfSense-module-0.13

While yes blocking rfc1918 and bogon on your wan is a common normal security practice.. To be honest its not really one of your bigger bang for the buck items..  And can cause more issues then it worth if you ask me.. All unsolicited traffic inbound to your wan is going to be block right out of the box.  So the only thing that would allowed in is stuff you have forwarded on purpose.  Or something that was in answer to a connection you made. So since rfc1918 and bogon do not route on the internet.  The only possible places where those address could actually talk to your wan would be if they came from your ISP.. So what if there is a misconfigured idiot on your same isp that is talking from bogon or rfc1918.. And he hits your open port - that you have open to the public internet anyway!

Yes, it should work assuming that you have two interfaces in the computer running pfSense software, one for WAN (Openreach pppoe) and one for LAN (BT Hub). I have never tried a BT Hub without the DSL plugged into it but I am using other wireless routers as access points successfully. I would tape over the BT Hub DSL port and make a note for others that this port is redundant because you are using the Openreach modem instead.