For our needs we need the tpm.ko module in order to get device attestation in Azure IoT Hub. We have a tested and working solution already on 2.6.0.

It would be fine to have such modules on packages instead of being included into the main build.

I would heavily discourage to drop all modules from production builds without having packages for them available.

Re: 2.7.0.a.20230510.0600 diag/ping only works by selecting WAN-address

I installed from scratch again (fifth time) but problem came back again. I can't install anymore packages, the "list" is just empty. And I can't install patches either.

I am getting tired with 23.05-RELEASE and probably will just cancel that VPS.

Or take a look at the other side...

[Marked solved because I have to switch, this VPS from IONOS will not run with pfSense Plus]

@datacenterdude

Either way, since 23.01 is also on BSD14, what would be the easiest way for me to get back to 23.01-stable? Both Current and Latest versions on System > Update show as:

2.7.0.a.20230510.0600

I would stay aware to march this road! It is related to the kernel modules (amount). With 2.7 Devel you get actual
only something around of ~80 kernel modules, but with
23.05 RC you will get back fully 822 modules and so it
might be the better choice to walk along with;
2.6 > 22.50 > 23.01 > and perhaps 23.05 RC

I was doing a fresh install of 2.6 and then I only put in the
token for pfSense Plus and set up the WAN gateway as the default GW and upgraded until the last 23.05 RC was reached. For sure you may be stay and hold on 23.01 release if you wish.

Hover over the icons, those are two different actions to take. The first one kills the connection but the client can immediately reconnect. The second sends a signal to the client that it should terminate and not reconnect.

Only P2P instances have an up/down indication in the widget. If a client is listed for an SSL/TLS multi-client setup, then it's up, so showing an icon saying it's up would be redundant since it can never be in the list and be down.

@stephenw10 said in UEFI install does not work on two older UEFI systems:

Hmm, I think that was probably after the changes went in then but certainly worth retesting.

To make matters more comlicated I just recently noticed that there are
different combinations of UEFI install.
GPT UEFI
and GPT BIOS + UEFI
I think default is the BIOS + UEFI
This is probably for compatibility and will boot either mode.
I now have to keep that in mind if the upgrade issue happens again and try both.
Lately I have been installing GPT/UEFI to make sure I'm not creating a bios bootable system.

Any reports in the past were all using the default fully automatic partitioning install.

In realtek-re-kmod pkg is not in the 2.6 repo so it's slightly more difficult to install since you need to pull it from the appropriate FreeBSD pkg repo.
On the other hand 2.6 is built on a FreeBSD release version which means pkgs can be updated from there. 2.7 is built on a FreeBSD 14 snapshot which means most packages will refuse to install or run if you try to use anything from outside our repo.

Steve

@stephenw10 Yep just saw that...
It's working on the latest build!
Very cool!

/usr/sbin/tcpdump -ni bge0.5 -c 1000 -U -w - '((port 25)) and ((not vlan))'

For reference: https://forum.netgate.com/post/1102125

Current snapshots have been restored; there was an error in the script copying them.

The Feb 15th snap is retained because it's the last snap with php81 which allows upgrading to 23.01 directly.

Steve

@jimbob-indiana I'ts doing alright after switching the driver (updated on another thread)
That I created specifically about the driver.
I was not familiar with changing the driver nor was I familiar with how to do it in 2.7.0DEV
Vs. 2.6.0

-Steve

See: https://docs.freebsd.org/en/books/faq/#lock-order-reversal

And: https://forum.netgate.com/topic/174821/reporting-lock-order-reversal-lor-backtraces

Yes, they are unwanted but mostly harmless. You are seeing them because witness is enabled in 2.7 snaps currently.

Steve

@stephenw10 I don;t have much detail yet.
But started a new post where I'll update that as I learn more:

link text https://forum.netgate.com/topic/179686/any-changes-to-intel-nic-vlan-support-in-2-7-to-be-aware-of

Easy to reproduce on 5 different systems.
I don't see any other posts about it.
I went ahead and filed an issue in redmine on this.
https://redmine.pfsense.org/issues/14305

Interesting for me only the Feb DEV version is available for down load.

Celeron N5105 is a Jasper Lake CPU, there are known issues with Proxmox on there but IIRC they are solved in the latest version of Proxmox with current CPU microcode. There are multiple threads about it on the Virtualization category here.

Those look more like out-of-state packets not random probing. Still normal and expected:

https://docs.netgate.com/pfsense/en/latest/troubleshooting/log-filter-blocked.html

Something may be causing more states to be dropped from your table faster than expected, but AFAIK there haven't been any changes in the code that would do that, so it may be something in your config or situational. But really those are normal, servers just keep sending packets to old connections in hopes that they're still open because it can be faster than setting up new ones.