@digdug3:

Maybe the other post (https://forum.pfsense.org/index.php/topic,72289.0.html)  is having the same issues due to IP6?

There is no such relation unless you assign the OpenVPN interface (which you should NOT do in 99% of cases.)

2.1.1-PRERELEASE (i386) built on Mon Feb 10 07:07:46 EST 2014 FreeBSD 8.3-RELEASE-p14

Running fine with failover… working as per previous posts, and new bits also working - Traffic Graph displays traffic for "Remote" and "All" filter selections, when adding/editing rules "LAN net", "WAN net" etc are shown in the standardized form.

Changes to pfSense 2.1 branch are here: https://github.com/pfsense/pfsense/commits/RELENG_2_1
Changes on pfSense-tools (where apinger and other ports/patches live) are here: https://github.com/pfsense/pfsense-tools/commits/master
But there is nothing recent that would help make those packet loss calculations any better or worse.

Feb 8 14:10:33 ntpd[34622]: restrict ::: KOD does nothing without LIMITED. Feb 8 14:10:33 ntpd[34622]: restrict 0.0.0.0: KOD does nothing without LIMITED.

So should "kod" also be removed then?

@jimp:

@Jason:

Any idea why the interrupts are fairly low on the box running 2.1?

I'm not sure but I'd have to say it's a difference in the way the driver is hitting the hardware. Either it is using a different tactic (e.g. interrupts rather than MSI/MSIX) or it's being reported differently by the driver, or it may just be driving the card harder using it more fully.

Speaking of MSI/MSIX, have you tried running with that forced off?

loader.conf.local settings for that are:
hw.pci.enable_msi=0
hw.pci.enable_msix=0

Not since upgrading to 2.1.1, no.  Getting rid of that setting was one of the reasons I upgraded a box before 2.1.1 was fully baked.

I'll give it a try.

EDIT:  With MSIX disabled the box gets stuck in a reboot loop.  It happens at the line "Configuring VLAN interfaces".  No output past that, it just reboots.

Snort is alive again.

2.1.1-PRERELEASE (i386) built on Thu Feb 6 02:09:11 EST 2014

Thanks,
Dick

The update just released appears to correct the issue.

@kswtch:

A similar behavior is observed in multi-WAN setups when one gateway goes down. apinger stops monitoring the gateway and therefore never sees it coming up again. The gateway is not usable unless apinger is restarted. This has been reported in Bug #742. The bug is closed since some years but still present in the current release. Maybe someone can reopen the report and look into it.

Does anyone have a suggestion on how to get apinger checking the gateway again after it went down? A watchdog isn't going to help here because apinger is happily monitoring the other gateway.

Thanks,
Daniel

Check solution here https://forum.pfsense.org/index.php/topic,69533.msg394384.html#msg394384
I created script for cron to restart apinger each 5 minutes.

2.1.1-PRERELEASE (i386) built on Sun Feb 2 12:42:30 EST 2014 FreeBSD 8.3-RELEASE-p14

All is well. I tried pulling out the phone line on the ADSL (default gateway), the dynamic DNS name, OpenVPN road warrior server and 2 OpenVPN site-2-site clients all switched to using OPT1. Plugged in the phone line again, ADSL negotiated, apinger detected the WAN online again, everything failed back.
Pulled the cable on OPT1 (which had general internet traffic directed to it as tier1 of a gateway group). General browsing failed over to WAN. OpenVPN server and clients remained running untouched (as they should because they were already on WAN - so no need to restart them).
During messing about, ADSL WAN went down by itself - had some minutes with both WAN and OPT1 down, and things recovered fine from that as links became available again. Always good to have the ISP give you a real test  ;)
Gateways log tab has nice clean entries like this:

Feb 3 10:24:32 apinger: Starting Alarm Pinger, apinger(28478) Feb 3 10:30:25 apinger: SIGHUP received, reloading configuration. Feb 3 10:52:28 apinger: ALARM: WANGW(8.8.8.8) *** down *** Feb 3 11:00:52 apinger: alarm canceled: WANGW(8.8.8.8) *** down *** Feb 3 11:08:57 apinger: ALARM: WANGW(8.8.8.8) *** down *** Feb 3 11:09:10 apinger: ALARM: OPT1GW(8.8.4.4) *** OPT1GWdown *** Feb 3 11:10:49 apinger: SIGHUP received, reloading configuration. Feb 3 11:12:59 apinger: alarm canceled: WANGW(8.8.8.8) *** down *** Feb 3 11:20:12 apinger: SIGHUP received, reloading configuration. Feb 3 11:20:23 apinger: alarm canceled: OPT1GW(8.8.4.4) *** OPT1GWdown ***

I think it is ok now. Running the latest "built on Fri Jan 31 10:30:26 EST 2014" snapshot for about three hours.

I don't know how apinger does the calculations but I had a lot of delay messages but without the 255 exit codes after this update.
I just deleted the gateway under Routing:Gateways and recreated it with another name.

Thanks!

@jimp:

Next new snap should be OK.
https://forum.pfsense.org/index.php/topic,71555.msg393514.html#msg393514

Yep, works!  :D

It's the same core issue as apinger and others, I'm not sure what the status is but I haven't seen a confirmed fix yet.

The next run (not the one uploading now, but the one after) should be OK again.

You have the "exited with status 255" error that others have, as well as apinger actually dying.
Like: https://forum.pfsense.org/index.php/topic,71555.0.html and other threads.
Moderators: this thread is best moved to the 2.1.1 Snapshot Feedback and Problems board.

I had 1 cluster member on 1.2.1 prerelease and the other on 1.2.0 RC1 for about a day with the backup (1.2.1) as master.  I just upgraded both to 1.2.1 pre-release.  We will see how it goes.

This network doesn't have any complex configuration but I do use it to test new things I want to use in other production environments.  It is mainly to offload web traffic to a cable modem and some other non-critical uses that does stress the connection at times.  I have redundancies built into the proxy setup I implemented internally so that any downtime will shift the traffic to the production internet connection within about 10 seconds of web requests timing out (perl script that runs constantly and switches out proxy configs to a backup link if it fails).

fixed, thanks

Thanks Jim!