Yeah, you're right it doesn't refresh anymore. I verified it works in 2.0, won't be fixing in 1.2.x as there likely won't be any more releases.

just reporting another successful upgrade to 1.2.3 release
i uploaded the image from work, instead of local network, which i probably should have done
but i was eager to update to the release version

i was using a snapshot from late nov, dont remember the exact date

i used the following upgrade image
pfSense-1.2.3-RELEASE-4g-nanobsd-upgrade.img.gz

system
alix 2d2, w/ 4gb hitachi microdrive, atheros 5008 wirless

You can safely increase the rate to 30 seconds, it should not affect the graphing.

When I initially wrote the package I added a large part of the lcdproc drivers list to the drop down, which means that they are not all usable.

The pyramid driver is the one I originally wrote the lcdproc package for and that one works well. I see it on my desk everyday.

If somebody offered me money to do the rest I might consider.

The image size auto-detection did not work properly, and there wasn't enough time to make it work properly and safely before the release.

All true - Stick with the Hitachi's

This is what I had to do to get my microdrives working and this is what you may need to do,

Boot the 1.2.x install CD
Set LAN IP
Do a fresh full install (99) to your microdrive as if it were a real hard drive.
REBOOT (remove CD)

(Microdrives don't like running at anything above PIO4 so in your PC BIOS Disable UDMA for IDE devices)
If you don't do this you may not even be able to boot or you will get the spinnig cursor but it will spin REALLY slowly.

Hit the space-bar when the kernel is loading (not at the Default F1 prompt) a little after, you should get an OK prompt.
Then type;

OK set hw.ata.ata_dma=0
OK boot

It should then boot all the way up to the pfsense menu.

Drop to the shell by pressing 8

Now edit /boot/loader.conf using vi;

vi /boot/loader.conf

Press the 'i' key and then move the cursor to the end of the last line and hit the enter key,
add the line;
hw.ata.ata_dma=0

so it looks like;

autoboot_delay="1"
kern.ipc.nmbclusters="0"
hw.ata.ata_dma=0

then press Esc flowed by :wq

Then press 'Ctrl D' to get back to the menu. Now you can restore your config by going to the web interface and quitting the wizard by clicking on the pfSense logo a couple of times.

And the following reboot should boot fine without any kernel flags as you have already set them. If you restore your config before you have edited /boot/loader.conf you for some reason, on the subsequent reboots, can't input kernel flags and your install will be dead as you are now stuck in some weird catch 22.

If you wish to update in the future your modified loader.conf will be overwritten, to fix this…

touch /tmp/no_upgrade_reboot_required

Run a firmware update as you normally would, but it won't reboot at the end.

Go back to a shell and then redo your loader.conf changes, and reboot.

can u plz post a screenshot of ur traffic shaper rules coz the problem i face when wireless is bridged to lan is that in and out interface if is elect as opt1 then traffic goes to that queue but after some time traffic stops to the wireless interface.

the scrren shot below shows i want to shape traffic of 2 wireless clients but if i set it from wan to opt1 and opt1 to wan ten non of them will be able to surf nor any other wireless clients but if is et it to wan to lan and lan to wan then its no problem but then there is no shaping for those clients. i recommend u restart ur firewall after applying those wan to opt1 and opt1 to wan rules or atleast resetting ur state table then try surfing.

rules.JPG
rules.JPG_thumb

Never heard of that, works on all interfaces on all my systems.

thanks for clearing that up. i've downgraded from 1.2.3-RC3 to 1.2.3-RC1 and remote access VPN is working again. With 1.2.3-RC3 I would see phase 1 then phase 2 but not ESP packets, just lots of phase 2. 1.2.3-RC1 works well enough for me.

hopefully some work gets done on 2.0 in the future. i tried a snapshot on the weekend, i now understand the meaning of "alpha-alpha"

Perry,

It could be related but it is quite different …

If you look at the schema you will see that the webserver is using OPT2 at the Main pfSense and the mailserver OPT1 at the Main pfSense.

The "bad packets" go away at the WAN of the Main pfSense and they are logically blocked at the LAN of the second pfSense, named pfSense Load Balancer.

This is because "bad packets" are from OPT2 and OPT1 and sometimes from LAN of the Main pfSense. It seems like the Main pfSense is loosing this packets for any reason and they go away for its default gateway (the WAN). All subnets are different, NAT, routes and ARP tables are correct.

Regards,

Josep Pujadas

@stephenyeong:

I have this issue too, using latest snapshot version of 1.2.3rc3

I just comment out one line on folling file to make the box not apply idle_poll again.
/etc/inc/pfsense-utils.inc
line 1103
mwexec("/sbin/sysctl kern.polling.idle_poll=1");

By doing that, you never enabled polling. That sysctl is what actually enables polling.

Polling works by using idle CPU cycles to poll instead of using interrupts.

It is not "stealing" or "hogging" your CPU time. That is just how it works. There is no problem here, it's just a cosmetic difference in how CPU time is reported.

Just a reminder.  Hope this gets into the "fix" list for version 1.2.3