The submitted crash is in ALTQ, you might try removing the traffic shaper and upgrading and see if it's stable that way. db:0:kdb.enter.default>  bt Tracing pid 12 tid 100006 td 0xfffff8000396b000 kdb_enter() at kdb_enter+0x3b/frame 0xfffffe00f439f820 vpanic() at vpanic+0x19f/frame 0xfffffe00f439f8a0 panic() at panic+0x43/frame 0xfffffe00f439f900 hfsc_dequeue() at hfsc_dequeue+0x633/frame 0xfffffe00f439f940 tbr_dequeue() at tbr_dequeue+0xdf/frame 0xfffffe00f439f990 vlan_start() at vlan_start+0x12c/frame 0xfffffe00f439f9f0 tbr_timeout() at tbr_timeout+0x57/frame 0xfffffe00f439fa20 softclock_call_cc() at softclock_call_cc+0x18a/frame 0xfffffe00f439faf0 softclock() at softclock+0x94/frame 0xfffffe00f439fb20 intr_event_execute_handlers() at intr_event_execute_handlers+0x20f/frame 0xfffffe00f439fb60 ithread_loop() at ithread_loop+0xc6/frame 0xfffffe00f439fbb0 fork_exit() at fork_exit+0x85/frame 0xfffffe00f439fbf0 fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe00f439fbf0 --- trap 0, rip = 0, rsp = 0, rbp = 0 --- That said, I'm running 2.4 on an APU (first gen, not APU2), with traffic shaping on and it doesn't crash there. I'm using PRIQ though, not HFSC.

i have to back to v4.0rc, so v2.4.1 newest version ipv6 down.

@PiBa: @marjohn56: the problem is on reboot. What problem? No pfBlocker rules are loaded. I have to do a force update. My patch and script means I do not have to anymore, it's done automatically.

Doesn't look like FreeBSD likes it hard set like that: Aug 25 00:40:43 charon 13[KNL] <con3000|21>unable to add SAD entry with SPI cf9ff216: Invalid argument (22)</con3000|21>

Great. Thanks for testing. I have closed the Redmine issue

@jimp: What about on the most recent snapshot as of now? Forgot to update this last night.  As of 2.4.0-RC (amd64) built on Wed Aug 23 05:47:05 CDT 2017 FreeBSD 11.0-RELEASE-p12 working now.  :) Thanks!

Today's RC works just fine.

Just checking to see you were awake.. 8) Yeah.. I had a brain fart moment, going back to sleep now!

If that doesn't work, try this: https://forum.pfsense.org/index.php?topic=135582.msg742380#msg742380

Indeed it would. I would expect to see errors/collisions on the interface in Status > Interfaces if that is the case. You may also see it running at some odd speed/duplex. Steve

Visit System > Update, make sure you have "Stable" selected. Click Save even if you did not change anything. Then, from a shell prompt, run "pkg update -f" and then "pfSense-upgrade -d" If that still fails, post the full output.

Normally I would agree about the untested hardware.  This is an unusual case in that regard though.  The client has a problem with getting hit by lightening.  They have had the problem for years and haven't been able to find a good solution.  As a result they end having to replace equipment fairly often.  So they are more concerned about price point than using untested hardware.

I'm having similar issue. On build from 6th, but whenever I update, it reboots and still shows older version. Then after that, it no longer sees version newer than build from 17th, the one I tried to update to. Everything is working again. It didn't even complain.

Tried workaround, but it does not work.  Thanks for proposal. Reason it does not work, is that the Gateway for the OpenVPN interface is still up, and therefore the Rule is still valid. The bug is in the implementation of the OpenVPN Client function.  If the specified underlying interface (for OpenVPN) is not available the OpenVPN Client interface should not be established. Another bug is that gateways which are down are marked as "Unknown" which pose other problems, e.g. it confuses the dynamic DNS updater which regards these interfaces as being up (and therefore does not refresh the ddns address). pfSense runs ok for me when everything is up.  But I find it impossible to seamlessly transition to LTE when the fibre link goes down.

Hi My Lan is a parent interface of 2 Vlan's. When someone transfere something from internet on one of the Vlan's interface the Lan interface have the same bandwidth usage (if no one use Lan otherwise it sum the  bandwidth). Ideally, in my case, should be the bandwidth used in Vlan not sum in the Parent interface. Some stuff i can point is the rule from Vlan to internet have a limiter. The double bandwidth is solved in Vlan's interfaces.

@jimp: It may be a catch-22 it's in now. When you update, the package may not actually be present/active at the moment the shellcmd to apply patches wants to run at boot time. Not sure if we have any viable way around that at the moment. Yes, makes sense. Thanks for the info.