rate hanging it? That's the only thing I've seen of late, a 'killall rate' also brings it back to life.

When I encountered the issue, for some reason I had the distinct impression it was hanging @ getting a WAN dhcp address.  Possibly why using an existing config avoids the issue?

Wasnt there some update or something for the dhcp daemon around 10-16?

Should be fixed up on the next new snapshot (hopefully).

If downtime is that critical, you should be updating during a low-traffic or overnight maintenance window when it won't matter quite so much.

A real hacky way to do this would be to install the shellcmd package and then add an earlyshellcmd to run

Which would remove the file that triggers the pkg reinstall.

If something breaks in a package because of the upgrade though, you've only got yourself to blame. We reinstall them for a reason, as cmb mentioned.

I can also confirm that the reboot (After disabling DHCP for IPv6) has stopped these log entries from appearing.

@jimp:

Yep, flaky BIOS is flaky.

Strange world… Incredibly complex BIOS code that allows extraordinary things like AMT yet is not able to supply something as basic as CPU/MB temperature readings via ACPI coherently on an standardised manner.

Either way, coretemp (which if I would have been a bit more diligent I would have found out that is part of pfSense since last July or so) gives a more accurate reading. Thanks again for your help.

I wound up doing a clean install. With both VPNs the memory is around 65%. Having only 1 or 0 servers active seems to avoid any issues on the bootup. RADVD still doesn't start with bootup (is it just me that's seeing this?) and the DNS forwarder seems to not listen on the IPV6 LAN address.

Connectivity works well enough once I start RADVD manually as the DNS forwarder listens on IPv4 still.

Hmm that doesn't sound right.
When you say 30 secs lag do you actually mean nothing happens for 30 seconds?
At home I am in a densely populated urban area surrounded wifi (over 100 networks when I last used kismet) and have no such problems. I'm using a mini-pci card in the pfSense box.

Steve

Your solution works for me. Thanks!

@phil.davis:

/etc/rc.php_ini_setup sets:

max_execution_time = 900

Normal things done on the GUI, even downloading and installing an update, should never use more than 900 CPU seconds on any platform.
Things like lcdproc are scripts that run forever in the background, so it will clock up 900 seconds of CPU eventually and get terminated by the PHP interpreter.
By adding set_time_limit(0) before loop_status is called in lcdproc_client.php it should be allowed to run forever:

/* Connect to the LCDd port and interface with the LCD */ $lcd = fsockopen(LCDPROC_HOST, LCDPROC_PORT, $errno, $errstr, 10); if (!$lcd) {   lcdproc_warn("Failed to connect to LCDd process $errstr ($errno)"); } else {   set_time_limit(0);   build_interface($lcd);   loop_status($lcd);   /* loop exited? Close fd and wait for the script to kick in again */   fclose($lcd); }

(The fragment above is from the version in the lcdproc package - lcdproc-dev is a little different, but same principle.)
Give this a try, then this should be fixed in the lcdproc / lcdproc-dev packages.
Any other packages that use a PHP script as a background process that runs forever will also eventually reach the 900 second limit - they will also need set_time_limit(0) added.

Solved! The v2.1 Beta is fine…no problem at all!  :)

It was a somewhat broken switch, which sometimes connects only at 10MBit via autosensing - I was so "into" pfSense, that I forgot to check the other hardware. Sorry...

Plz move this topic to /dev/null...  ;)

any updates regarding aes-ni not working?

i have a test environment with aes-ni capabilities that i'd be more than happy to let you use for testing.

Hi!

That would be even better as interface status already has a widget and it makes more sense that uptime is displayed there…
For pppoe users uptime is easy to read :)

Devs what you say, can this be incorporated in future builds?

Regards,
Greg

If my memory is correct, you should search the pfSense forums for some system tweaks to address this. A search string such as "igb receive structures" might turn up something useful.

Okay, I've checked out the latest snapshot for Oct 23, 2012.

When using the traffic shaper wizards, the LAN shaper rules are now first instead of the WAN rules. I'm accustomed to seeing the WAN rules listed first. Does this matter?

So we now, well…I now have listed as follows...

LAN
-qLINK
-qInternet
----qAck

WAN
-qAck
-qDefault

VLAN A
VLAN B
VLAN C

Thanks for your answer!

I did a re-install after all. (it was a new one)
I used the same CD but it works correctly now.

just to let people know … i had a bug open in redmine : http://redmine.pfsense.org/issues/2611

still open.