Shell users do not work like GUI users. We don't yet have a way to safely give them the same permissions as the admin user. We don't display the menu because it will not work properly for them.

The widget doesn't ping the gateways, it only reports the times as kept by apinger. It simply reads the status output from /tmp/apinger.status and formats it for the gui.

The apinger process controls how often a monitor IP gets pinged, and that is controlled by the settings under System > Gateways.

any update?

Take a look on this topic

http://forum.pfsense.org/index.php/topic,50840.msg288228.html#msg288228

I will try to find the log files for the laptop also from pfSense for that timeframe, but it will be the end of the week before I get back to the home lab.  I can assure you that the laptop has never had a network connection that would allow it to be on the public leg of the network.  It's the only Windows box that I allow at the house…a Dell netbook that my niece returned to me when I gave her a Macbook Pro last Christmas.  Everything else here is either Linux/CentOS, FreeBSD, MacOS, SGI or Sun.

Thanks!
David

One more thing…I did manage to kill the symptom by configuring a static reservation on the opt2 dhcp config.  That forced the unit to get an address and use the name that I had assigned to it.  After stopping the service, killing the dhcpd.leases file and restarting the service with the new host reservation, it doesn't seem to be killing my syslog file any longer.  But as I said, I resolved what would be a "symptom" of the actual problem.

Most DHCP servers implementations with which I work on a regular basis have a method of generating a client hostname if none is returned by the client.  If that doesn't exist, some of those implementations will build a hostname out of the mac address by removing the ":" and either replacing that with "-" or nothing at all.  This, combined with some bounds checking on the hostname returned by the client, would likely resolve the problem going forward.  I haven't dealt with the "dhcpleases" issue before in any of the commercial stuff before.  Most of that is obscured by WebUI or API and I don't have to go to the actual process level on the boxes.  Sorry I can't be of much more help here.

David

Update to the newest snapshot to make sure the changes caused by the widescreen package are gone.

Disabling Acpi stopped the clobbering of the log.
I can live with the side effects.

Thanks!

I bumped it on 2.1, no need to address that for 2.0.2 since it only applies to IPv6

@phil.davis:

Found the problem. Pull request https://github.com/bsdperimeter/pfsense/pull/224
Now I can delete old offline dynamic leases.

Thanks.  I just bumped into this problem myself…your fix works great for me.

Bruce.

@yon:

why not use the MAC address for ipv6 ?

Please read this entire thread. That has already been discussed in depth on the earlier posts in this thread.

Impossible to tell until the whole file is downloaded.

Sorry rcfa, I saw it only today.

Try to clear crash report/php error, check and save squid gui tabs before testing again.

Thanks Jimp and sorry for my late reply….

I have experimented with bringing a DHCPv6 WAN up and, while it still spikes, it can be brought under control by removing the interface (which I guess is expected behaviour).  This is on the following version:

2.1-BETA0 (amd64) built on Sat Sep 15 17:04:58 EDT 2012 FreeBSD 8.3-RELEASE-p4

I believe I probably need to go back to the drawing board and consider if I'm approaching my v6 setup in the correct way (as you indicated in (b)), although it seems that https://redmine.pfsense.org/issues/2555 is continuing to move along.

I got it working. I modified the rc.newipsecdns script in /etc. I added

sleep(15) and
vpn_ipsec_force_reload();

This is my working version :

#!/usr/local/bin/php -f
/*
$Id$
part of m0n0wall (http://m0n0.ch/wall)

Copyright (C) 2007 Manuel Kasper mk@neon1.net.
Copyright (C) 2009 Seth Mos seth.mos@dds.nl.
All rights reserved.

Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:

1. Redistributions of source code must retain the above copyright notice,
  this list of conditions and the following disclaimer.

2. Redistributions in binary form must reproduce the above copyright
  notice, this list of conditions and the following disclaimer in the
  documentation and/or other materials provided with the distribution.

THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY
AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY,
OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
POSSIBILITY OF SUCH DAMAGE.
*/

/* parse the configuration and include all functions used below */
require_once("config.inc");
require_once("functions.inc");
require_once("filter.inc");
require_once("shaper.inc");
require_once("ipsec.inc");
require_once("vpn.inc");
require_once("util.inc");

/* make sure to wait until the boot scripts have finished */
while (file_exists("{$g['varrun_path']}/booting")) {
sleep(1);
}
$ipseclck = lock('ipsecdns', LOCK_EX);

if(isset($config['ipsec']['enable']))
{
sleep(15);
log_error("IPSEC: One or more IPsec tunnel endpoints has changed its IP. Refreshing.");

}
/* We will walk the list of hostnames found in the ipsec tunnel

configuration. Since we are already triggered by filterdns that a hostname has changed we can proceed to compare the new IP address with the old address from the DNS cache.
*/
vpn_ipsec_configure();
vpn_ipsec_refresh_policies();
vpn_ipsec_force_reload();
unlock($ipseclck);
?>/seth.mos@dds.nl/mk@neon1.net

@cmb:

When you're changing around versions you're accessing on the same IP address, it's very common for your browser's cache to hose things in ways that are similar to the screenshot shown here (amongst other possibilities), that's my guess as to why since it's not replicable.

It's possible. I do clear out my cache quite regularly, but I can't remember if I had done so in between the last test of the install on the 4G CF & this one on the 8GB. But I had definitely done the force refresh a few times and it still had it. However, I do believe that this is the likely prognosis.

Thanks,
Jason

Update: I can lend further credence to Chris' statement. I copied the notices from another system that is have CARP sync errors (second device is detached presently) and it didn't cause the cosmetic issue and I was able to clear selected or all notices without issue right from the WebUI. Thanks for highlighting the importance of clearing the cache with these WebUI anomalies

CARP IPs each have unique MACs. I've done numerous such setups, it works fine.

See the other forum post on this: http://forum.pfsense.org/index.php/topic,53647.0.html
JimP's latest commit should have fixed it.