@cwadge:

I'm discovering that on the latest nightly of 1.2.1rc1, the interface does get marked down after a few seconds. But unfortunately, the failover never actually takes places. If the interface goes down, it's simply down until you bring it back up. The downed network never falls back to the other gateway.

Ahhh, please disregard this. After some further troubleshooting, it turned out that the core router I was using to gauge uptime for that interface could be reached through either interface.

However, that does bring up two interesting points.

It took about 1 minute for the connection to completely fail over. The hardware is a dual 600MHz P3 with 384mb RAM, but it seems to be the loadbalancer that's taking so long to recognize that it's down, not the filter reload afterwords.

In this situation, I can only assume (until I dig a little deeper) that the PFSense box automatically started pinging the other gateway's core router through the gateway that was up. I'm not sure if this is considered a bug or just an undesirable feature… but ultimately, what's the difference?

Ok, I can report back that when running pfSense 1.2.1 in cdrom mode, the captive portal doesnt seem to be able to find the files one uploaded via the CP upload interface. HTML loaded via the main CP config page does work however.

I have since installed the pfSense onto the machines in the CARP cluster onto their hard drives with success. However, it would appear that now the captive portal is half broken. Basically, if I turn on the captive portal and try to connect to a webpage through the pfSense CARP cluster I never get redirected to http://10.0.0.1:8000/ for login. If I go into the captive portal setup and click on the link that takes me to the CP login the page loads and I can authenticate my MAC address via a username & password setup in a FreeRADIUS server running on the pfSense box.

So in summary, HTTP redirect to CP login is NOT WORKING. CP login page will load if you go to its URL directly, and logins do get processed then.

I have also run into other issues with CP + FreeRadius that I will detail in another post since they are separate from this issue I believe.

Sounds like a possible regression in the FreeBSD ath driver from 6.2 to 7.0. Post the dmesg as wallabybob suggested.

You are trying to nest aliases?!

Prolly as php date will show UTC time.
http://www.worldtimeserver.com/current_time_in_UTC.aspx
If you execute " date " in Execute Shell command or goto http://yourpfsenseip/status.php
you will see your local time.

Enable keeplive in your SSH client.

Is this on the latest Update?

go to status.php, paste your rules.debug shown on that page.

If I set it to auto I get that error when it tries to switch to channel 6 which I assume it would start off at channel 6 and then scan around for best clear channel.

If I set it manually to channel 6 it works fine, just not in auto.

I can also select other channels and it works fine.

I have a feeling the auto is not reading the configuration information correctly which may work fine for other wi-fi cards while mine is a little picky with certain settings.

there was a problem with an updated zoneinfo, tomorrow's snapshots should be fine.

Cool - thanks for the info.

try a new snapshot, this should be fixed.

Please test latest snapshot should be fixed.

@GruensFroeschli:

The embedded version is in no way different from the full version
except: no data will be saved to the disk (i.e you cannot install packages, RRD graphs wont be stored to the disk, etc.)

Just for the records, actually graphs will be stored if you shutdown/reboot cleanly and kept for the next boot. At least on the 1.2.1 I am using.

They're stored in memory in the meanwhile though, so if you just plug off the power cord they won't be retained.

@zarthan:

I have been using PFSense for a year or so and am tickled with how it performs. Many thanks.
The reboot page should refresh to something like the system page. I can't tell you how many times I have restarted the router because I mistakenly refreshed the page or re-opened Firefox with saved session only to have the router restart again.

Just commited a fix for this to 1.2.1 and 1.3.

@zarthan:

This is really a trivial thing. I often set up a router without actually connecting the WAN port simply because I want to complete some things before I actually install it or I'm replacing a router and can't connect the WAN port. The startup scripts take considerable time waiting for a wan connection and then even though there is no wan connection will try to sync time etc. I'm sure I'm not the only one that does this and when you have multiple restarts, well it just annoys. Should have looked at the scripts before I started this.

Addressed in 1.3.

@zarthan:

There is no logout for the GUI or timeout.

Addressed in 1.3.

Considering that PSense 1.3 is a long way out I really appreciate that PFSense 1.2.1 will be running FreeBSD7.

No, sadly I don't think you're missing a tome of pf wiki-wisdom. Yes, I agree with you.  DHCP sync-over and fail-over would be on my request list too.
But a bug-fix forum is probably not the best place to get feature requests noticed.
On the bright side, you can sync NAT and rules which alone saves you quite a bit of time a…

Nick.

ok scratch that–i had some windows firewall issues

Just a hint that pfSense 1.2 is based on FreeBSD 6.2 and 1.2.1 made the transition to FreeBSD 7 already.
Hopefully this doesn't matter here.

You could try fetch from console

fetch http://cachefly.cachefly.net/100mb.test
or
fetch http://mirror.cogentco.com/pub/linux/centos/5/isos/x86_64/CentOS-5.2-x86_64-bin-1of7.iso

Extra could be to ssh pfSense and open more windows and use commands like
top -SI
sysstat -vmstat or -ifstat or -iostat or -tcp

http://www.freebsd.org/cgi/man.cgi for more info on those commands