Thank you! I appreciate that alot!

@techpro2004 "It is not enough to succeed; others must fail." —Gore Vidal Schadenfreude (/ˈʃɑːdənfrɔɪdə/; German: [ˈʃaːdn̩ˌfʁɔʏ̯də] (About this soundlisten); lit. 'harm-joy') is the experience of pleasure, joy, or self-satisfaction that comes from learning of or witnessing the troubles, failures, or humiliation of another. But, Seriously, we should hope that all these projects succeed in bringing the software to parity with the OS releases, rather than doing the "Backport" dance.

@bmeeks said in Suricata Upgrade and Crash: Those are harmless warnings. Those warnings have zero to do with your WAN traffic graph issue. You have some other issue with your firewall configuration. The messages are just saying there are no rules files in that Suricata interface subdirectory. Thanks Bill for the reassurance...I mentioned only the WAN traffic graph issue because the graph had started and when I clicked to see the report then return to the dashboard, it stopped. Suricata was running and I didn't restart it; so, the report was puzzling.

We know, but we do not need nor want LibreSSL in our builds. It still doesn't work with OpenSSL 1.1.1. I updated the text on the 2.5.0 release notes a while ago to reflect that change.

Sorry to reply to myself but just found this in the debian forums for the same issue. Perhaps it's a simple power control setting in the bsd driver that is disabling the NIC? Message #26 received at 928328@bugs.debian.org (full text, mbox, reply): From: "Rene 'Renne' Bartsch, B.Sc. Informatics" rene@bartschnet.de To: 928328@bugs.debian.org Subject: Re: Intel I350-NIC shuts down ports after loosing carrier Date: Fri, 3 May 2019 11:01:42 +0200 echo on > /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/power/control echo on > /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.1/power/control echo on > /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.2/power/control echo on > /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.3/power/control solves the problem. This should be "on" by default instead of "auto". Regards, Renne

That's an invalid selection, though input validation isn't checking for it and it should. It rejects IPv6 and ARP but not IPv4 and ARP. (ARP is neither, technically) I did also find a way to eliminate that PHP error, though.

Look at FreeBSD, that's what pfSense is base upon. https://www.freebsd.org/cgi/man.cgi?query=bgpd 2.5 is a development snapshot and not the current stable version.

Almost a year now. :(

yes. i see it now.

Hello, this is now fixed in the latest snapshot.

The latest snapshot has resolved the issue. Great work!

Should be fixed in upcoming snapshots: https://github.com/pfsense/pfsense/commit/4bdbb8987eeb62a41ef6e92c1abf7a9befb90f20#diff-ec6446a5e0ba1355743271751e3154a5

Thanks again.. Always good to renew my FreeBSD editing skills. :) Back up and running. 2.5.0-DEVELOPMENT (amd64) built on Tue Dec 31 09:11:09 EST 2019

There aren't any known issues with 2.5.0 on SG-3100 at the moment. I'm running it on two of them. There are problems with 2.4.5 yet that are being worked on, but 2.5.0 should be OK for the moment. You might actually have a hardware issue there that maybe isn't being hit in the same way by 2.4.4, or it might be a bug in FreeBSD 12.0 that will be resolved once the 2.5.0 base is moved to 12.1/12-STABLE. If you are OK on 2.4.4 then it is likely fine, but keep an eye on it.

@Gertjan said in System Update GUI shows wrong version number for the Latest Base System: Probably because their is a lot of build activity these days. See github logs . Something about finalizing a soon to come release update ? Also : I presume that the building phase usage stages. The latest 'version' isn't the one that present to sync with. Building takes time. edit : you have 20191229.1128 It proposes 20191230.1623 and it will download (several seconds later) 20191230.2321 (a little bit more recent). Not bad, you'll getting better as proposed. What do you want more ? ^^ Nod bad, really. But it's happening all the time I am on the development builds, thats a couple of years, I think, sometimes it differs ~12h or even more. I know it's cosmetic bug and developers don't need to waste their time on it... just asked why

This crash in bgpd seems unrelated to the ntpd issue this thread was started for. You should open a new thread for it. Steve