This problem is now fixed.  1.0.1 will be out later this week which includes this and other misc bge fixes.

Hitting enter in the menu without any other input will refresh the page too.

from 1.0 rc3,a,b,c,d,e,f you can upgrade to 1.0 release
works fine

fixed this issue by adding this to my squid.conf on host 192.168.0.12

httpd_accel_host virtual
httpd_accel_port 80
httpd_accel_with_proxy on
httpd_accel_uses_host_header on

thanks hoba.

i used sysctl to disable device polling, but then i just switched it off via the GUI.

Now got a real syslog server receiving everything.

Since them I noticed high load on the box, ntop was taking 100% of one CPU.
I've now disabled / uninstalled it - but this could be the source of my issues (even though in that case it shouldn't crash the box).

Now waiting to see if everything is stable again.

@ginosteel:

How i can fix my problem if every time i make a reboot i need to add the following lines to setup WAN.
ifconfig fxp1 down
ifconfig fxp1 inet …... netmask .....
add route default ......
my problem is that pfSense dont want the configuration that i make

You turn down the interface and it magically works????  WTH, you've got some seriously broken hardware.

–Bill

@xibalba:

Hi,
  Currently running 1.0-RELEASE. When I set my Virtual IPs on my WAN interface, and login to the pfSense machine via SSH and drop into a shell. I notice (even after a reboot) that my WAN interface (vr0) is not setup with the Virtual IPs I entered into the GUI. I had to create a shell script in /usr/local/etc/rc.d/ to set the aliased ips at boot time. Has anyone else expierienced this?

pfSense VIPs don't use the interface aliases in FreeBSD.  You're working to hard at this and overthinking the solution.  Use proxy arp or CARP VIP types instead of "other".

–Bill

Go to https://www.grc.com/x/ne.dll?bh0bkyd2 and hit proceed. Then click one of the desired scans. It will scan your from the internet and report back in a html page what's open, closed, stealth,…

http://whatsmyip.org/ports/ offers a similiar service.

you could also place some scripts in /usr/local/etc/rc.d/ to run after the system boots. Make sure to chmod +x the script. I had to do this because pfSense didn't seem to properly bring up my aliased IPs on my WAN interface.

Yep, this has been pointed out on both the mailing list and the cvstrac bug tracker.  Both places have the recommended fix.

–Bill

Please open a ticket at cvstrac.pfsense.com and include as much info as possible. Thanks!

Oops, forgot the javascript, lol.

// the routine for the info center upshrink echo ' '; //This is for the pop menus echo ' '; echo ' ';

That starts on line 144, it should anyway, highlight the lines all the way down to the tag and replace it all with the previous code.

@caps_phisto:

Noticed a quirk.  It seems that I was overrunning the default state table size.  I've noticed it for a while but didn't think anything of it until I read this post http://forum.pfsense.org/index.php/topic,71.0.html.  I have over 400 users here so I would assume based on what was posted there 10k States just isn't enough.  This also correlates with the times that the connection "goes down", as it normally goes down during high traffic periods(noon/after dinner).  I have reset the Max States to 1million.  As the post above stated it was under System -> Advanced.

Thanks.

Back to waiting…

10K -> 1 million is a helluva jump.  You might want to scale that back some…say to 100K or 200K? :)  This thread might be useful to you http://marc.theaimsgroup.com/?l=pfsense-support&m=114771925530407&w=2

–Bill

Thanks, this is fixed. Basically you have installed a package of some sort and on bootup the package is not found.  You may have to remove the package info from /cf/conf/config.xml and then delete /tmp/config.cache

Does anyone have a Script to share capable of monitoring task(s) something like this ? …

1. Verify T.1 Task(s) are active process(es) in good condition as far as can reasonably be determined, if not take T.2 action.
2. If any T.1 Task(s) are consuming over C% CPU, checked every I time interval, occuring R number of times in a row, then take T.2 action.
3. Check the system.log every I time interval for occurance(s) of L.1 string list, if found take L.2 action.
4. If ping times to P.1 host are above P.2 ms, checked every P.3 time interval, occuring P.4 number of times in a row, take P.5 action.

Example Constants I define: T.1=('olsr','dnsmasq') : T.2=('reboot', 'restart'), C=30 %, I=30 sec, R=3, L.1=('hardware failure','halted') : L.2=('reboot','reboot'), P.1='192.168.1.1', P.2=500 ms, P.3=30 sec, P.4=5, P.5='reset ath0'),  -- actions: 'reboot'=reboot, 'reset ath0'=reset interface, 'restart'=run /usr/local/etc/rc.d/'T.1'.sh but if restart or reset fails or is triggered again within 12hrs then reboot.

If not, I may post a small bounty.
Thanks,

Pete