Messages

I went with three columns. With the firewall PIE chart, if you click on any part of the PIE, a live log for that interface will open in an external tab. The letters to the left of the PIE can be toggled on and off to show or not show on the pie by clicking.

I think I will try three columns. At first, I forgot to lock the layout as it is unlocked at first login after the update, at least for me it was.

 I still do not quite know what to make of the new dashboard so I am feeling it out whether I want to or not. How many columns wide seems to work best for all of you? I have 5 but..... something still doesn't look right.

Edit, I attached an AVIF with three columns.

Yes, when it goes down the first time and it begins to reboot it stops and does the kernel update then reboots and starts the package update and reboots. Tells me how major of an upgrade this is.

 This update takes a while so if it seems like it's taking a long time, it is but there is nothing wrong. Don't reset or anything, just wait.

You did the right thing.

PHP 8 has had some things changed and not all third party software seems to be ready.


Cheers,
Franco

The 3rd party plugin is no longer available in recent versions anyway. Once I removed those two pieces I haven't had any surprises.

Looks like PHPmailer doesn't fully support PHP 8 yet. Bummer.


Cheers,
Franco

But do we really need it with the config backup mailer gone?

Was I right to remove it? The backup mailer became defunct because your team had questions about security. I see the php mailer and os-mail-backup as residual because once it became defunct with an os upgrade, there was no way to remove it through the gui. If I had downgraded, removed the plugin and then upgraded again at that time I am sure none of this would have happened unless you know better.

My config file no longer has that defunct plugin so if I did a clean install with the new config I doubt the php mailer and the os-mail-backup would ever be installed. I will find out on Saturday as I am building a fanless machine that is in a 1U case that has heatpipe and a huge heat sink on one side. Because of the heat sink it can only take a mini-itx. EPCY 3000 series are in my future. With these cases the power can't be over 95 watts.

 I get this:
PHP Fatal error:  __autoload() is no longer supported, use spl_autoload_register() instead in /usr/local/share/phpmailer/PHPMailerAutoload.php on line 45

Is this a residual from when I used to have my config files mailed every night? That plugin was deprecated and there was no way to remove it within the gui so I hand edited it out of the config and reloaded it so I would not keep seeing it in the plugins as unavailable yet no way to remove it once updated.

EDIT SOLVED:
I simply uninstalled PHPmailer from the command line and it also uninstalled os-mail-backup. Now the Cron starts with no errors.

> Well, the kernel is temporary.

This doesn't make any sense.


Cheers,
Franco

The version.

I'm still suspecting the kernel has a hand in this which makes it difficult to nail to some single change/component.

Going backwards on complex changes such as DNS registration behaviour is not easily possible due to larger code changes involved, but also not relevant given the ways to pin this down to a clear confirmation (is it core or is it kernel).


Cheers,
Franco

Well, the kernel is temporary. I wonder who else besides me had this issue caused purely by DNS overlap and now are no longer flapping? I've been solid since I got rid of the overlap. I also wonder if those who used compiled out of kernel drivers and say it stopped flapping, did not also make configuration changes that in themselves may have actually fixed it by getting rid of overlap. The other thing that raises eyebrows is that only that one interface was involved, not the others as many people have igb nics on all interfaces and they also use that same driver module. 

Thanks folks.

 Hello all, of course google's dns came up in a wan flapping thread and now that I am not using google's dns for anything, I still noticed that there are things on my lan that are using 8.8.8.8 so they must be hardcoded because I never put them there. As far as DNS, I am using one of two authoritative dns servers at the datacenter where I have a few VPSs running and then the backup DNS servers come from level 3. For my gateway monitoring I don't use DNS servers at all anynmore but rather have each of the two gateways ping one of my servers running on VPS instances and only I can tell these servers not to accept the. Each gateway pinging once every second only uses 6MB per gateway in 24 hours so let it roll. Before I was using Google dns servers in monitoring and dns and then started flapping so now no two ip addresses are used twice in anything related to dns or monitoring. Franco mentioned that some ISPs force their users through Google which as he said is Mean and I agree.

Now I discover that smart TVs, smartphones and other things have 8.8.8.8 hardcoded in them. Has anyone ever blocked these and if so, does it force those devices to use the DHCP server in OPNsense thus using the DNS servers WE chose or does the device lose it's ability to resolve dns?

If we want to throw diffs around maybe start with the most obvious:

Our stable/22.1 branch differences against the main FreeBSD branch with the latest and greatest code for the em(4) driver:

% git diff --stat upstream/main sys/dev/e1000 
sys/dev/e1000/e1000_phy.c |  2 +-
sys/dev/e1000/em_txrx.c   | 13 ++++++++-----
sys/dev/e1000/if_em.c     | 32 +++++++++++++++-----------------
sys/dev/e1000/igb_txrx.c  | 21 ++++++++++++---------
4 files changed, 36 insertions(+), 32 deletions(-)

As such I doubt that the current driver situation gets much better than what we have with FreeBSD 13 right now and additional driver updates even from Intel are out of the question for direct release inclusion (kmod packages can be used but that's all there is).


Cheers,
Franco

This is the most meaningful diff, thanks for that, I haven't git pulled them and ran a diff on them. Has there ever been consideration into using deltas? I know there are good reasons for doing a full download and good reasons for using a delta but the delta can only upgrade the most recent version before the update it provides. Just curious.

As far as Intel goes, they have not updated their out of kernel driver source in two years and probably no need to. Nobody has shown me a log that points to the Intel or Broadcom driver (there was a reported flapping with Broadcom) when their wan flaps and if it was indicated, I just do not see how an interface would be able to bring itself back up once the kernel throws a driver error for that device so the driver would be the last place I would have looked. I've never seen a NIC module recover the hardware once a kernel error is thrown without recycling power to the nic which we have no way to do on a running system. All I have seen is igb up and igb down or em up or em down with zero kernel driver logs from anyone. My case was simply overlap caused by misconfiguration that now is rightfully caught by the upgraded system and WAN hasn't cycled a single time since.

I had this DNS overlap on 1 device originally, and fixing it definitely made the problem better, however i still got flapping on the wan every 2-3 days until I replaced the driver.  All of my primary WANs are Comcast (some residential DHCP  others business static), so it's possible that Comcast has made a change to their systems that's sending something funny.

I would think that if there were a driver issue, the interface would fail and the interface would never come back up on it's own. I would want to see a kernel log entry that points to the driver causing anything. A driver failure is not easy if even possible to recover from without a reboot. They just don't automatically reload and bring back up the interface as far as I know.

Rather than throwing things at the problem, I created a diff file between the in kernel source and the latest BSD driver from Intel which is not that new either. The trouble is that the diff file is 1MB in size and I cannot attach it here. There is more in common between the two than there isn't.

Here is a snip that even contains the command I used:

diff -Naur /home/dave/src-release/13.1.0/sys/dev/e1000/e1000_80003es2lan.c /home/dave/em-7.7.8/src/e1000_80003es2lan.c
--- /home/dave/src-release/13.1.0/sys/dev/e1000/e1000_80003es2lan.c   2022-05-11 16:59:24.000000000 -0700
+++ /home/dave/em-7.7.8/src/e1000_80003es2lan.c   2020-04-08 08:13:17.000000000 -0700
@@ -1,32 +1,31 @@
/******************************************************************************
-  SPDX-License-Identifier: BSD-3-Clause

-  Copyright (c) 2001-2020, Intel Corporation
+  Copyright (c) 2001-2019, Intel Corporation
   All rights reserved.

Yes, I know that the current kernel is 13.0 but the intel driver code even in 13.1 is dated from 2020 and that's just the copyright, the driver itself goes back much further.

The file is much too long to paste in here. If I could get the attachment size permission raised to 1MB I could attach it here. The + and - lines are what is added and subtracted to the old source source code in this instance to make the new driver. The in kernel driver is older than I thought so there should be no new issues with it. Even the next version newer than the in kernel version was released in 2016.