@jcyr:

'Pigning' is ICMP. If it was responding to ICMP when asleep then the existing conflict avoidance already built-in to dhcpd would work. My phone is Android 4.2, so I can try it. Furthermore I have it set to disconnect when sleeping.

That's what I mean, I didn't know the DHCP server had that conflict avoidance, it should be fine :) As for your phone, one - it doesn't affect Android 4.2, and two - it doesn't affect phones that disconnect when sleeping :)

Here's details on the bug: http://www.net.princeton.edu/android/android-stops-renewing-lease-keeps-using-IP-address-11236.html

I noticed it personally the first time two nights ago, a device in DHCP leases "online and expired"

@churnd:

I just upgraded.  It seems to be OK, but I don't know if it was because I patched it myself yesterday or what.

When you upgrade /etc/inc/system.inc will be overwritten, so this bug is gone.
I will close this topic.

@Nachtfalke:

Since pfsense 2.1 is using .pbis the packages are independent from eacht other. Each package uses its own dependencies and other packages do not influence this package.

But you should check if your packages are testes and do work with pfsense 2.1:
http://forum.pfsense.org/index.php/topic,50603.0.html

That may be the case in the strict sense of the definition of package dependencies, and it's a progress over earlier versions, but there are other things. Like nothing stops you from installing two packages that do the same thing, which is easy to do, because several packages do multiple things, and most are not listed by function but by some fantasy name that the project gave itself, which incidentally is also then a problem in the menus, because related functions are not grouped, which they were if things were named according to the service they provide. Example: "http proxy" instead of SquidGuard, "http server" instead of apache, etc.
The project name could follow the description in parentheses or something like that but the name shouldn't obscure the function.

ah thanks… my last known status was from February.
Last week I tested with a virtual firewall some internal publishing and first connection try did not came up but after quickly inserting these option.
So my first thought was that it has still not been implemented... but rechecked it now with tcpdump sniffing and it looks good... Thanks ;)

Added a bug for it: https://redmine.pfsense.org/issues/2979

"You can't do proxy ARP with failover" - Thank you !!!!
That exactly was a problem ….. I just realize of constant proxy on BOTH servers, ( initially assuming such configuration is dynamically on/off on the second node )

So the right steps:
1. create 3 CARP IP addresses
2. list this 3 IP addresses as 1 Alias
3. NAT any -> Alias pool from p.2
4. set pool option

Can someone advise a pool option (3 options) : round-robin sticky ; random sticky; hash ? (behind approx 40 crazy servers with 2-5K connections to outdide in a time frame)

Thank you all.

I just finally managed to update after a two hour long download of the image.
All is fine now, running latest build.

thanks!

Our IPv6 connectivity at that colo had issues overnight with our routed connectivity. Hopefully should be back to normal ASAP.

I see it now in snapshot and it works, but there is another problem;

After installing latest snapshot and reboot, Status: services still shows vhosts as stopped, but actually it is running;

[2.1-BETA1][root@pfsense.localdomain]/root(14): ps -ax | grep vhost
97972  ??  SN    0:00.07 /usr/local/sbin/lighttpd -f /var/etc/vhosts-http.conf
26964  0  S+    0:00.00 grep vhost
[2.1-BETA1][root@pfsense.localdomain]/root(15): ls -l /var/run/vh*
-rw-r–r--  1 root  wheel  0 May  1 22:39 /var/run/vhosts-http.pid
[2.1-BETA1][root@pfsense.localdomain]/root(16):

the /var/run/vhosts-http.pid file is empty.
if I put the PID "97972" into that file, then check the Status: services, it now shows running.

The problem appears that the PID is not being saved into the PID file upon startup.

Seems to be fixed.

Every reference I see to that error on the web has to do with some sort of BIOS/ACPI/CPU interaction.

The only driver-related change since April 9th was to a NIC, ixgbe, so it's not likely to have caused that.

im curious what drivers does pfsense use and their version for atheros chips

They weren't important. They'll have a performance improvement at some point in the future if they can be stabilized outside the main tree first.

Thanks - I'll give it a try in a couple of days and let you know.  Adrian.

i found the "issue"

if im change that line

msgid "%s made unknown change"
msgstr "%s made unknown change"

like

msgid "%s made unknown change"
msgstr "%s bilinmeyen değişiklik yaptı"

using turkish characters all pfsense xml write attempts fails

msgid "%s made unknown change"
msgstr "%s bilinmeyen degisiklik yaptı"

im used english characters only a "değişiklik" word and i wrote a comment note for other ppl for dont change that line.

If the IP is all 0's, and it's set for DHCP, that usually means the DHCP lease expired and it can't renew it.

That is often, but not always, an issue with the ISP or modem. It could also be an issue with pfSense and DHCP on that particular snapshot.