@stephenw10 said in Intel Xeon D-2796NT and QAT: So before you enable SR-IOV you can't pass through the PCIe devices directly? Yes, it was, thanks for the train of thought. :) (control plane is needed) Only the pass-thr. the Virtual Functions does not work. I updated Intel FreeBSD 1.x VIB to the latest version on ESXi. I revoked all pass-thr. and PCI assignments in ESXi and pfS VM -- & SR-IOV off in ESXi on C62X After updating VIB, I was able to enable only the pass-thr. of C62x chipset device, which I transferred to the VM as a complete PCI device. Seeing the complete device, pfSense was able to assign a driver to the QAT C62X. [image: 1762511051996-d4ea54e4-ac73-4d9a-8202-02502dc9c22c-image.png] [25.07.1-RELEASE][root@ngfw.rm.arpa]/root: sysctl -a | grep 'qat' qat0: <Intel c6xx QuickAssist> mem 0xffb40000-0xffb7ffff,0xffb00000-0xffb3ffff at device 8.0 numa-domain 0 on pci4 qat0: qat_dev0 started 8 acceleration engines qat0: FW version: 4.18.0 qat0: Excessive clock measure delay qat_ocf0: <QAT engine> irq135: qat0:b0:277 @cpu0(domain0): 0 irq136: qat0:b1:279 @cpu0(domain0): 0 irq137: qat0:b2:281 @cpu0(domain0): 0 irq138: qat0:b3:283 @cpu0(domain0): 0 irq139: qat0:b4:285 @cpu0(domain0): 0 irq140: qat0:b5:287 @cpu0(domain0): 0 irq141: qat0:b6:289 @cpu0(domain0): 0 irq142: qat0:b7:291 @cpu0(domain0): 0 irq143: qat0:b8:293 @cpu0(domain0): 0 irq144: qat0:b9:295 @cpu0(domain0): 0 irq145: qat0:b10:297 @cpu0(domain0): 0 irq146: qat0:b11:299 @cpu0(domain0): 0 irq147: qat0:b12:301 @cpu0(domain0): 0 irq148: qat0:b13:303 @cpu0(domain0): 0 irq149: qat0:b14:305 @cpu0(domain0): 0 irq150: qat0:b15:307 @cpu0(domain0): 0 irq151: qat0:ae:309 @cpu0(domain0): 0 dev.qat_ocf.0.enable: 1 dev.qat_ocf.0.%iommu: dev.qat_ocf.0.%parent: nexus0 dev.qat_ocf.0.%pnpinfo: dev.qat_ocf.0.%location: dev.qat_ocf.0.%driver: qat_ocf dev.qat_ocf.0.%desc: QAT engine dev.qat_ocf.%parent: dev.qat.0.frequency: 685000000 dev.qat.0.cnv_error: dev.qat.0.fw_counters: dev.qat.0.mmp_version: 6.0.0 dev.qat.0.hw_version: 4 dev.qat.0.fw_version: 4.18.0 dev.qat.0.heartbeat: 1 dev.qat.0.heartbeat_failed: 0 dev.qat.0.heartbeat_sent: 1 dev.qat.0.dev_cfg: [GENERAL] dev.qat.0.num_user_processes: 0 dev.qat.0.cfg_mode: ks dev.qat.0.cfg_services: sym;dc dev.qat.0.state: up dev.qat.0.%domain: 0 dev.qat.0.%iommu: rid=0x440 dev.qat.0.%parent: pci4 dev.qat.0.%pnpinfo: vendor=0x8086 device=0x37c8 subvendor=0x8086 subdevice=0x0000 class=0x0b4000 dev.qat.0.%location: slot=8 function=0 dbsf=pci0:4:8:0 handle=\_SB_.PC0G.S9F0 dev.qat.0.%driver: qat dev.qat.0.%desc: Intel c6xx QuickAssist dev.qat.%parent: D-2145NT CPU only 1 "ch" QAT implemented [image: 1762512285003-18cdec9a-fa83-484f-acd9-5e7207d29906-image.png] The original goal was not to assign all VFs to pfSense, but with this CPU, it is necessary because there is only one "ch" QAT. For example, D-2187NT CPU has 3 channels (3x16VFs), where other VMs can also get a QAT device if needed. The lesson is that cannot use SR-IOV first, but must need pass-thr. the entire device to the pfS guest. On Linux, for example handles this and explicitly recommends that in case multiple QAT "CHs", - VFs should be symmetrically distributed to the guest(s). D-2187NT offers greater flexibility if you want to run more than just pfSense guests on ESXi, as QAT capability remains available for other VMs. I should note that I am STILL a fan of bare metal pfSense, but there are cases where paravirtualization can help. This is now the case. And honestly, after so many years away, it was good to return to pfSense. It never disappoints. I did skip the PLUS licensing thing (but the TAC was fair), but Netgate is right: counterfeiters MUST be stopped somehow! @stephenw10 - THX

I'm hijacking this post because it seems my problem is somewhat related to this. Difference is that I don't use home.arpa domain https://forum.netgate.com/topic/199239/kea-dhcpv6-dns-registration It seems that a single host in my static allocation is only found in NDP table with <hostname>.unknown.home.arpa instead of my properly set domain name. Other hosts are properly being registered. And yes, the host is Ubuntu Server. And in pfsense /etc/hosts there's no mention of this entry with its GUA IPv6, only its IPv4 reservation also made by KEA DHCPv4 and a static IPv6 ULA entry made in Unbound itself under DNS Host overrides. One thing it did occur to me just now, is that the static allocations that do resolve in DNS properly were setup prior to switching to KEA (when I was using ISC). This unifi one was setup after I moved to KEA. PS: The addresses that are not properly registered for you (::1003, ::1005) etc. seem to occur if you have "Enable early DNS registration" in KEA Settings for DHCPv6. If you uncheck that, it will properly resolve only the full IPv6 with the proper prefix from your ISP. This issue seems to be fixed in future 25.11 release.

@q54e3w I sent the devs a fix and thought it was addressed. Maybe its only in the next release of pfSense. There is a line in the error which contains single quotes vs double quotes. Old: $csvline = str_getcsv($pfb_buffer, ',', '', '"'); New: $csvline = str_getcsv($pfb_buffer, ',', '"', '"');

said in 25.11 BETA - What's new?: Online Patch 3 days ago @rpotter28 This may help Redmine pfSense Plus v25.11 Oops The above is just the 20 redmine pfsense plus - target 25.11, for which there are probably no plans to ever release to pfsense CE The better group is Redmine pfSense - Plus target v25.11 (108 issues, some of which maybe released to CE at some time)

https://github.com/woffko/pfSense-pppoe-ha/blob/main/pfSense-pkg-pppoe-ha/stage/usr/local/sbin/pppoe_ha_event.php A bit improved code and logic.

@stephenw10 nothing in the logs for the DHCP client. I will enable the debug logging and check the logs upon the next reconnect

@bmeeks Yep, in this case I am just talking about the kernel source. The head for CE kernel is still public from what I can see, its for whatever reason the 2.8.0 and 2.8.1 branches are not.

@w0w thanx, now all typing-in works well and fast

Also see: https://docs.netgate.com/pfsense/en/latest/development/develop-packages.html

Yup, seeing that here. Likely related to the upstream firmware API issue. But those drivers shouldn't need to load anything without the hardware present anyway.

I suspect the root cause here is the same as this: https://redmine.pfsense.org/issues/15770

@luckman212 I use a manually added FreeBSD package, 'munin' that came with a file to be placed in /usr/local/etc/rc.d/ As per pfSense needs, I renamed it - added the .sh extension, and now the munin process get started at boot, and stopped at shutdown. I made this install many years ago, and as far as I know, the script only executes during boot and system shutdown. Not for network or other events etc. If FreeBSD would look like a Debian system (or clone) using init or systemd I could tell you way more, and I even think pfSEnse isn'tv really FreeBSD (no surprise, at it is, and it isn't ^^). Look at the kea script for an example, the first 3 / 4 lines. Afaik, pfSense it self, see here /etc/, all de rc...... files - for example rc.bootup - will all all these files. pfSense handle the hardware and software system events, and call whatever is needed, if system processes like 'unbound' needed to be restarted. So : and also during certain system events (e.g. interface link changes, IP address changes, and gateway events). never saw that happening with my own processes - as pfSense isn't really aware that these are running ones the system is up.