i had already reported this
http://forum.pfsense.org/index.php/topic,24077.0.html

There isn't much of any difference in doing CARP on 2.0. It should all be the same.

The bridged interface can cause you some trouble though, as with a CARP pair that can lead to a layer2 loop unless you are using smart switches with STP. I think in 2.0 you can adjust the STP settings for a bridge though so it might be doable.

You could also use a CARP devd hook to bring down the bridge if a system is the backup. There are instructions for that in a sticky on this board. It says CD-ROM platform in the title of the thread but my post there will work on anything.

Also, it's covered a bit better in the book.

Yes, I can confirm it working for me as well. It's the main reason I'm using pfSense instead of my home brew linux firewall where I only switch WANs on a host bases instead of protocol and time etc…

As a follow-up to myself, the problem may be related to a problem with the CD-RW I use. Had installation problems with another distro which has been solved by burning the image on a DVD-RW using a different writer.  ::)

Hope this can help someone else!

Ark

i fixed /usr/local/www/services_dhcp.php
"edit file" instrument correctly saved file to /usr/local/www directory.

now all works good. thanks for help.

some more stuff

Apr 4 11:51:47 dhcpleases: lease file nees to exist before starting dhcpleases Apr 4 11:51:47 php: : The command '/usr/local/sbin/dhcpleases -l /var/dhcpd/var/db/dhcpd.leases -d pfsense -p /var/run/dnsmasq.pid -h /var/etc/hosts' returned exit code '1', the output was 'lease file nees to exist before starting dhcpleases: No such file or directory'

Ermal just bumped the date on FreeBSD RELENG_8, and ipfw is missing at the moment. Try later.

same on 3rd april nanobsd

I committed another fix which will hopefully cure the settings saving bug once and for all.

Wait for another new snapshot after this post and try it again.

Thanks, I wanted to post the manual work-around asap and felt obligated to give what debug info I had.
If the next rev is smart enough to swap configurations on its own, the whole issue will be OBE.

Given the importance of the state table size, it could be worthwhile adding sysctls to report the maximum table size and count of times the table was full and report these through the web GUI.

I left it for a long while and it eventually asked me where to find the root filesystem. I used ? to list valid devices and got a listing of the target hard drive (ad6) and the dvd (acd0, acd0t01) but neither cd9660:/dev/acd0 nor cd9660:/dev/acd0t01 succeeded in mounting the root filesystem from the DVD.

Any ideas?

edit: Efonne, at what point would I enter that command to disable dma? at the FreeBSD menu?

edit2: I booted in safe mode and it managed to mount the root partition this time.

I committed a fix for this. I had some similar functionality coded up in PHP, I just had to convert it to JavaScript (ick! :))

On Apr 3 snapshot, packets are not lost anymore. The issue was some how resolved.

The ping is very slow, however. The SSH console and the Web UI too. Roundtrip delay is now about 900 ms on average. It looks like everything is now getting into the qP2P queue, which is my Penalty and Catch-all queue (it is on the top on my Floating Rules page) and which is the only queue having an upper-limit curve width bandwidth=1%, m1=0, d=1000ms, m2=50%.

I'll send you my configs later when I'll get access to the local console. Now it is a real pain to work with it remotely.

I'll test the reloads later, as pftop is inaccessible in the current snapshot. Thanks for consideration.

Reply from 192.168.0.74: bytes=32 time=997ms TTL=62
Reply from 192.168.0.74: bytes=32 time=1000ms TTL=62
Reply from 192.168.0.74: bytes=32 time=1000ms TTL=62
Reply from 192.168.0.74: bytes=32 time=1003ms TTL=62
Reply from 192.168.0.74: bytes=32 time=1000ms TTL=62
Reply from 192.168.0.74: bytes=32 time=1005ms TTL=62
Reply from 192.168.0.74: bytes=32 time=1002ms TTL=62
Reply from 192.168.0.74: bytes=32 time=1003ms TTL=62
Reply from 192.168.0.74: bytes=32 time=1000ms TTL=62
Reply from 192.168.0.74: bytes=32 time=1004ms TTL=62
Reply from 192.168.0.74: bytes=32 time=1003ms TTL=62
Reply from 192.168.0.74: bytes=32 time=1001ms TTL=62
Reply from 192.168.0.74: bytes=32 time=1004ms TTL=62
Reply from 192.168.0.74: bytes=32 time=1001ms TTL=62
Reply from 192.168.0.74: bytes=32 time=1003ms TTL=62
Reply from 192.168.0.74: bytes=32 time=1009ms TTL=62
Reply from 192.168.0.74: bytes=32 time=1004ms TTL=62
Reply from 192.168.0.74: bytes=32 time=1000ms TTL=62
Reply from 192.168.0.74: bytes=32 time=1003ms TTL=62
Reply from 192.168.0.74: bytes=32 time=1000ms TTL=62
Reply from 192.168.0.74: bytes=32 time=1000ms TTL=62
Reply from 192.168.0.74: bytes=32 time=1000ms TTL=62
Reply from 192.168.0.74: bytes=32 time=1003ms TTL=62
Reply from 192.168.0.74: bytes=32 time=1001ms TTL=62
Reply from 192.168.0.74: bytes=32 time=1002ms TTL=62
Reply from 192.168.0.74: bytes=32 time=1001ms TTL=62
Reply from 192.168.0.74: bytes=32 time=1000ms TTL=62
Reply from 192.168.0.74: bytes=32 time=1001ms TTL=62
Reply from 192.168.0.74: bytes=32 time=1000ms TTL=62
Reply from 192.168.0.74: bytes=32 time=1002ms TTL=62
Reply from 192.168.0.74: bytes=32 time=1002ms TTL=62
Reply from 192.168.0.74: bytes=32 time=1001ms TTL=62
Reply from 192.168.0.74: bytes=32 time=1001ms TTL=62
Reply from 192.168.0.74: bytes=32 time=1000ms TTL=62
Reply from 192.168.0.74: bytes=32 time=1000ms TTL=62
Reply from 192.168.0.74: bytes=32 time=1006ms TTL=62
Reply from 192.168.0.74: bytes=32 time=1001ms TTL=62
Reply from 192.168.0.74: bytes=32 time=1000ms TTL=62
Reply from 192.168.0.74: bytes=32 time=1000ms TTL=62
Reply from 192.168.0.74: bytes=32 time=1000ms TTL=62
Reply from 192.168.0.74: bytes=32 time=1002ms TTL=62
Reply from 192.168.0.74: bytes=32 time=1001ms TTL=62

Ping statistics for 192.168.0.74:
   Packets: Sent = 32840, Received = 32814, Lost = 26 (0% loss),
Approximate round trip times in milli-seconds:
   Minimum = 0ms, Maximum = 1027ms, Average = 873ms

The builder run has to do 4 continuous complete runs to generate all sizes. If the build process is stopped and restarted, it resets.

Last I saw, there were some changes going on to try building with a more up-to-date set of FreeBSD 8-STABLE sources, which is likely the cause of it being restarted.

http://redmine.pfsense.org/issues/show/320

thanks, but when I use m0n0wall 1.2, 1.3, I can use other charset without change any source code!

@mabusoe:

When I try to look at status in openVPN I get this error message:

Warning: Invalid argument supplied for foreach() in /usr/local/www/status_openvpn.php on line 363

Oops ! I did not see your post in time. This issue is fixed now.

Pierre

I'm having the same issue here…
Running on pfSense 20100325-1036