Got another one snapshot and the problem has gone. Wonderful.
By the way, I think that the root cause was default gateway logic modification, for some reason it looks like resolver (unbound) did not used WAN on tier1 but used failback WAN2 on tier2 and WAN2 was just out of prepaid traffic. On the latest snapshot it using active gateway, currently WAN, so I hope the problem is solved.

After more investigation, it appears that the Suricata crash was PHP error indeed. A clean install of the latest pfSense 2.5 and a restored configuration revealed that the GeoLite2 DB update was enabled on Suricata's global settings. However, last May there was a similar PHP error that resulted invalid MaxMind key. That was changed when a reissued key had been applied on June 3rd. So, there should not have been an invalid key on June 27th resulting in crippling Suricata. Since the 27th, there has been issues with PHP and yesterday there had been five or six snapshots each with issues ... others have mentioned the same here: https://forum.netgate.com/topic/154898/2-5-latest-update-issue and here: https://forum.netgate.com/topic/154936/gateway-automatic-seems-to-have-quit-working-saturday-june-27-working-on-later-snap

So, I have disabled GeoLite2 on Suricata because I did not realize I had enabled it and it should not have crippled Suricata. My firewall is back to normal development testing with MaxMind enabled only on pfBlockerNG. I believe the developers might be pressured (self induced) to have a release candidate; however, the update installer should not be posing issues at this stage. The last snapshot update late last night had issues.

Screen Shot 2020-07-01 at 12.34.18 AM.png

@louis2
I am not sure what was the logic, but according to hint for this field
"If this field is blank, the adapter's default MTU will be used. This is typically 1500 bytes but can vary in some circumstances." it should use adapter's default MTU, but I think for PPPoE WAN type it should use something different.
If I type whatever I type into MTU field, for example 1500 I get

[wan_link0] PPPoE: Set PPP-Max-Payload to '1500'

in PPP log.
If I clear this field I don't get this line at all. Same happens if I put 1492 into this field, no payload is set, it's default.
Another one note. If I disable WAN and enable it, then my PPPoE interface changes it's parent interface to the last one in the list, I mean "Interfaces/PPPs/Edit" "Link Interface(s)" list. So my connection failed with same sympthoms as yours.

@Gertjan said in Random PHP Error recently occurring...:

@HITMAN said in Random PHP Error recently occurring...:

Resolves the issue until you update again, needs adding to the master.

Read again.
This is the master https://github.com/pfsense/pfsense/blob/master/src/etc/rc.dyndns.update - you can use that file to replace your rc.dyndns.update - eventually, an update will load ... the same file.

Yeah, sorry, mean't release updates, which i see the fix has now been applied with the most recent update today, thanks again and for the link to the fix!

Looks like the new code finally made it in to the current snapshot! Thanks to everyone for all the help and a special thanks to the Coders!

Thanks again Gertjan,

Glad that the issue is gone now ...

However I do only partly agree on your taxi driver, story. IMHO problems should be fixed where they are .....

Louis

Jimp,

I now and then have IPV6 related FW-rule-error messages, and also notice just like others "pfSense radvd[84278]: can't join ipv6-allrouters on ix1.116"

The FW-rule-load errors I sometimes see are related to throwing back traffic from the PCLAN towards the WAN-gateway, by explicit defining the WAN-gateway in the rule. The reason to do that is that accessing my services from my own network should pass the same filterrules as if they were comming from the internet

There were error(s) loading the rules: /tmp/rules.debug:530: no routing address with matching address family found. - The line in question reads [530]: pass in quick on $PCLAN $GWWAN_VLAN6_DHCP6 inet6 proto { tcp udp } from <myipv6-range-for-pc-subnet> to $MyPublicServersIPV6 tracker 1559247992 keep state label "USER_RULE: Route this internal traffic via the front door"
@ 2020-06-11 11:04:23

So that could be related as well.

Louis

@serbus Well John, early this morning I tried again and got same unauthorized ... so, I tried the browser and got invalid key; so, I just generated a new key ... all is good.

It's possible. There are other problems with RADIX_MPATH as well but I'm not sure if we're going to look into fixing them or back that out.

Hello,

I just discoverd that when I replace the interface names in /var/etc/pimdpimd.conf with the corresponding IP-addresses, a couple of error messages disappear.

However the issue that not all (vlan)interfaces have vifs stay, and at the end of the startup PIMD is still not running due to "Cannot forward: no enabled vifs"

also note that i am missing ^mrouting^ and my feelings are not changes since I created bug #9631 a year ago.

For those intrested some links:
https://troglobit.com/howto/pimd-on-freebsd/
https://troglobit.com/howto/pimd-on-openbsd/
https://www.freebsd.org/cgi/man.cgi?query=igmpproxy&sektion=8&apropos=0&manpath=FreeBSD+Ports+9.0-RELEASE
https://www.freebsd.org/cgi/man.cgi?query=mrouted&sektion=8
https://bsdrp.net/documentation/examples/multicast_with_pim-sm
https://github.com/troglobit/pimd/issues/78

Louis

@louis2 said in 2.5.0 reboot issue (after applying my config):

config.inc.lib line 383

https://forum.netgate.com/topic/148158/stuck-at-booting-after-upgrade-to-version-2-5-0-development-snapshot

@techpro2004 said in Been away:

At least you did not say soon. The question is "some" of what?

Well, you said it's probably "a few months out", then asked how many is a few... so the response of "some" would be referring to months. 😂

Maybe it'll be a nice present for us this holiday season? Surely everyone's being super-productive working from home! 🙂

It could be Realtek NIC. If it's possible, use other hardware, If not, you may need to compile realtek driver for your network card, not sure if it's still possible to with 2.5.0 but some people have compiled and using it
https://gist.github.com/jovimon/524e116471f249626fd2ccd141f3fe05 (pfSense user guide)
https://forums.freebsd.org/threads/replacing-realtek-re-driver.55861/page-2

@bmeeks Well, Bill, I had a wild Sunday morning with pfSense 2.5-devel 20200502-210 ... for some unknown reason, after the update; WAN would not load completing the boot process. I find that odd given I was running legacy mode. So, I decided to do a fresh install, update, and restore from backup.

The install and update went well ... as soon as I restore from backup, on rebooting, it stops ... WAN would not load. So, really wanting to preserve the configuration, I went through process fresh install, update and restore from a week earlier than the first. Same thing WAN would not load to compete the boot.

Ended, freshly install, update and fresh configuration. Suricata and Snort inline mode is working ... still more configuration to do however, this time I'll keep it simpler. Thank you for following up.

That must have changed recently, I didn't notice since I still had log content in that file:

-rw------- 1 root wheel 98767 Apr 30 11:40 vmware-vmsvc-root.log -rw------- 1 root wheel 140329 Jan 6 15:30 vmware-vmsvc.log -rw------- 1 root wheel 26386 Apr 30 11:40 vmware-vmtoolsd-root.log

I'll update the package