It was a private bug (potential security issue) so not visible to the world. It's closed now. :-)

The older menu entry is likely a leftover from the 2.2.x config that was not cleanly removed by the old package. You'd have to manually edit it out of config.xml to remove it.

Best one yet. Sadly no hockey mask included  ;D

Looking at the dpinger log, it is clear that there are no probes responses actually being received. The reason that it shows as "up" initially is because dpinger cannot declare any packets lost until the initial expiration of the loss interval (2 seconds). Beyond that, it's just how soon the page is refreshed.

So as to the source of the problem, something is dropping either the ICMP echo request or the ICMP echo reply. The first thing I would recommend is to try setting the dpinger Data Payload to 1 in the Advanced section of the Edit Gateway page (System / Routing / Gateways / Edit). If this fixes it, it means that some network element in the path simply has a defect in the handling of ICMP packets. It's not a problem to continue running with a small data payload.

If setting a Data Payload doesn't fix it, it likely means that some element along the path is actively suppressing ICMP echo packets. To determine where, you would need to start exploring with ping and traceroute. An example for ping would be:

ping -S src_addr 8.8.8.8

For src_addr use the IP address of your firewall (same as the -B parameter to dpinger). If you want to mimic the behavior of dpinger, you can add a size parameter:

ping -S src_addr -s 0 8.8.8.8

An example for traceroute would be:

traceroute -s src_addr 8.8.8.8

By default traceroute uses UDP packets. To use ICMP packets instead, you would use:

traceroute -s src_addr -I 8.8.8.8

Traceroute allows you to specify a packet size, but does not allow a zero size payload.

Additional options for ping and traceroute can be found in the FreeBSD man pages:

https://www.freebsd.org/cgi/man.cgi

Thanks Phil, beat me to digging into that one. Merged.

@SnowGhost:

While your looking at check boxes, they should all be "tick for yes".  Not, "tick to disable".

That is much more involved than just flipping it in the html.  Has to be flipped in the config and logic where used.  You are certainly welcome to commit the contributions though.

As for looking at and updating check box text to be in title form I've not committed to doing that nor do I have an exclusive on that (not so subtle hint).

Just an update.  Went ahead and changed Update Settings from "follow 2.3 snapshots and move to automatically to -RELEASE (Default)" to "keep following 2.3 development snapshots."  Went back to System Update and the below showed:

Current Base System 2.3.1.a.20160428.0320
Latest Base System 2.3.1.a.20160512.0018

Proceeded to do a system update and am now at the latest snapshot 2.3.1.a.20160512.0018.

System dashboard now shows current snapshot version as well.

Version 2.3.1-DEVELOPMENT (amd64)
built on Thu May 12 00:18:20 CDT 2016
FreeBSD 10.3-RELEASE-p2

In addition, with the fix on the Update Settings page (https://redmine.pfsense.org/issues/6136), the options now appropriately say "Stable (Default)" and "Development Snapshots (Experimental)" for me.

All looks good!

I've pushed a fix

Extra users and groups are fine, I was mostly curious since before 2.3 released we had observed an issue with spaces in group names causing a problem with accounts being synchronized, I thought it might have been related.

@cmb:

Guessing it's already-established connections that are staying there maybe? That'd be expected.

it kept sending new clients towards tier2 for days after the gateway event … can't have been (all) established connections

@cmb:

Two things influence traffic routing. Guessing your clients are being routed via a gateway group, which you can verify on the back end with:

grep route-to /tmp/rules.debug

The other thing would be the default gateway, for traffic matching firewall rules set to "default" rather than a gateway group. Check Diag>Routes to verify that.

will check the rules.debug when/if it happens next

Merged, thanks Phil and Steve.

Guessing there was something else still hanging around from the changes you made that was causing an issue. Glad it's working now.

You are right.
Thank you  :-*

@JorgeOliveira:

Your PHP error messages are incomplete due to a bug that was recently fixed.

Also some of those messages have striking similarity with those here:
forum.pfsense.org/index.php?topic=110698.0;all
by hitting the issue on get_configured_interface_with_descr()

I'd recommend a gitsync to the latest RELENG_2_3 version which contains the following fix:
https://github.com/pfsense/pfsense/pull/2922/files

And applying this, might help as well:
https://github.com/pfsense/pfsense/pull/2925/files

Are these automatic if I’m on the snapshot branch?

@JorgeOliveira:

Do you have any packages installed?

Sure, a whole bunch…
…anything in particular you’re interested in?

It is fixed now… see rm ticket

Still this same phenomenon with Latest Base System 2.3.1.a.20160508.0101.

Due to 2 PID's of dhcp6c [Why?], WAN(igb0) cannot succeed, and/then LAN(igb1) is appointed but not effective.
To get rid of the ISP-IPv6 over igb1, a reboot is necessary.

This time I saw PPPoE(IPv4) was not established. So, is it eventually necessary that IPv6 should wait for IPv4 to finish successfully?

We always do. Even back further, 1.2.3, 2.0, 2.1 and 2.2.x were all tested direct upgrade to 2.3 successfully before release.

It's a matter of catching the specific circumstances that are a problem between versions. All the config upgrade issues are confirmed fixed, and the issues from old package files that may still be on the system is partially fixed.

Check your computer to see if it's transferring 2.5Mb/s?

nano's been there for a while.

Agreed. It is correct as-is. Capital=default action.

Sorry I missed this conversation. I'll address it later tonight.

It was an easy fix. Look for it in the next snapshot.

Scratch that, I had some spare time before escaping for the day so I updated to the development branch and the issue (with growl notifications) does appear to have been fixed. The password field in the webui is still indicating the wrong length (intentionally perhaps?), but it is authenticating correctly and sending notifications.

The fix broke the build of cryptostats so it was reverted. It'll come back once that issue is addressed.

nope

https://forum.pfsense.org/index.php?topic=111150.0

@phil.davis:

That is weird. The code is a foreach over all the interfaces:

foreach ($config['interfaces'] as $if => $ifdetail) {

It could have an "if is_array()" to protect it - that will stop those warning messages - but actually $config['interfaces'] MUST always have at least 1 interface in it. So something is going wrong with the global $config

Exactly what I was thinking.

IMO, the only way for that to ever happen is config.cache to be corrupted for whatever reason, so I've submitted the following PR:
https://github.com/pfsense/pfsense/pull/2925

Additionally, with regards to truncation of crash report, I've submitted another PR:
https://github.com/pfsense/pfsense/pull/2922

You mean the "wrote 3 leases to lease file" part? Probably has a third that dates back prior to your log. Check /var/dhcpd/var/db/dhcpd.leases

@Blade1:

I also notice that the CPU is stuck at 99%.

If you run 'top', or Diag>System Activity in the GUI, what process is chewing up the CPU?

Did you reboot after changing the timezone from UTC? Guessing not, some things will be on the old timezone until a reboot, php.ini among those. If I set my tz to America/Vancouver, and either reboot or run rc.php_ini_setup, I correctly get:

: grep timez /usr/local/etc/php.ini date.timezone="America/Vancouver"

@Steve_B:

Unable to reproduce this. What version are you running?

I can add/move/delete rules anywhere and the separators seem to stay where they belong.

Ditto.

That only tells you if an update is available not if a reboot is required.