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.

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

What can I do to give more information ?

Maybe some info on the setup of the client's that can't connect also are the using the same ISP.
basically what do they have common.

Excellent.  Thank you very much for the reply. I'll give it a shot tomorrow. I didn't think it was anything I was doing wrong.

@keylevel:

I've installed 1.2.3-RC3 on an Alix 3D3 (updated 3C3) and have had exactly the same problem.

I found that selecting the "no acpi" boot allowed the system to boot.

I then set the power management mode in the BIOS to APM and then re-installed (not sure if that was needed, but I changed the install media as well). This also boots ok.

Confirmed ! This solves the issue, alix3c3 boots right up with BIOS power management set to APM.

(I'll test on the 1c1 and 1d1 later and confirm whether fix works on those boards as well)

Thanks !

You're welcome. Glad it was such an easy fix  8)

No idea, probably, if HUP entails rereading the config file.

100% cpu usage is due to device polling so disabled that and solved it

–edit--
one more finding:
if i disable traffic shaper everything works like a charm but with it enabled, doesnt

--edit--
if wireless is bridged to LAN and if u need to have traffic shaping rules for wireless then packet in interface to select will be WAN as usual but out interface needs to be LAN (due to wireless being bridged to LAN) or opt1 (wireless) ?

--edit--
above question is relevant if traffic shaping is possible on bridged interface

hmm https dont wanna work with RC1 kernel.gz =(

this is impossible.  packets are not going to magically go from the WAN to your PC unless pfsense was set up to send them there.  either these are faked, or there is some trojan running on your PC which is letting stuff in (maybe something else, but no idea right now.)  or maybe a hacked zombie pc on your LAN which is spoofing the packets?  easy way to tell is to run tcpdump on the wan interface of the pfsense and see if you see those packets coming in at all.

To be frank I also had a downtime a few days ago.
I was getting device timeout messages for a while and AP was gone.
After rebooting my wireless clients and playing a bit with the AP settings it was back on (there isn't something specific that fixed it though).
Like I said I run the official 1.2.3RC3.
On the plus side stuck beacons are much more rare now but this device timeout is causing the same issue so I am happy the devs returned to 7.2 driver as it was better in that respect :)
To sum it up I guess we should just wait for 2.0 with 8.0 and hope drivers are better there.

thanks alot that corrected the issue

I tohught i checked that box  ??? but i guess i didnt

HAPPY THANKSGIVING PFSENSE!!!

here is the screenshot

Nice one pre made image thanks :)

I was having problems getting FreeDOS to boot.

Thanks Covex.
I used to backup my configuration file, and restore it.
Now i installed pfsense nanobsd and configured it by hand, just like the 1.2 version.
Now it all works.

Thanks again

@Papa:

Then what possible problem am I having because I can assure you I would love to take IPsec over PPTP. I can connect just fine if I try it internally, but the moment I leave my network and attempt it from the LAN, it fails.

Probably not forwarding all the required protocols and ports. Which you require will differ depending on what you're forwarding to and how that device is configured.

Is there a workaround?

I'm installing an ALIX w/microdrive over Thanksgiving and I'd like to set it up with the full install.

EDIT – Just use the "simple" install.  The kernel installation screen shows up in that mode!

I updated that page. The information it had was very, very out of date.

I reported that bug back in January 2008 - it's on the old cvstrac system here.

I'm not sure that it's going to get fixed now, as unless I'm mistaken, all this code will be replaced by the new traffic shaper in 2.0.

Last I heard, we're just waiting on FreeBSD to drop a Security Advisory and issue a patch for a vulnerability (OpenSSL, I think.)