"Recent posts
#51
25.7 Series / Re: After upgrade from 25.1.12...
Last post by BrandyWine - Today at 06:08:10 AM@rainerle
Your x722 is many/few revs behind.
You are currently at NVM 4.00 (software 23.4 or 23.5.2), which is just about dead middle of the Intel versions available.
The latest for x722 is from software 30.1.0.1 with NVM 6.50
Matrix here --> https://cdrdv2.intel.com/v1/dl/getContent/336882
In the features matrix you can see there's not much new from old stuff to new, mostly virtualization stuff. Well, it doesn't actually says if any issues for any feature was fixed, it's just a feature matrix, etc.
Here's the crux, Intel revision 3.5 is dated June 3 2025, freeBSD v14.3 release is dated June 10 2025, the Intel doc does not list freeBSD v14.3 as supported, but shows 14.1 for latest v14.x. EDIT: see below for the 30.4 Intel release info.
My guess is, the ixl kernel driver in freeBSD 14.3 should be ok, but it appears to not be validated by Intel (see notes about 30.4)
Upgrading NVM would be for two reasons:
1) needing a newer feature
2) possibly fixing issues (of which is not mentioned in the Intel doc)
For best possible function with less probability for errors, make sure the sfp's are "Intel validated".
See the bsd doc for ethernet/driver support --> https://www.freebsd.org/releases/14.3R/hardware/#ethernet
Since the bsd 14.3 doc does say ixl supports Intel 700 series, I think it's ok as long as the SFP's are Intel type, which your outputs appear to show.
The only caveat is, where did you get those Intel SFP's? Years ago I had issue with cisco switch gear that only played nice with real cisco SFP's, and the ones we got reported as "cisco" but were actual grayware that got into supply chain. Vendor got us new SFP's from another supply chain line and then all was good. This however was just turning up the SFP in a specific fiber mode.
All that said, the only eye-catcheris that the Intel doc does not list freeBSD v14.3 as supported, but the bsd docs seems to say ixl is good to go.
Is there something in the 14.3 ixl driver that is not playing nice with your older NVM? Possibly so. There's no matrix I can find that does back-versioning validation.
EDIT: So if you select latest release 30.4 and hit DOWNLOAD button (https://www.intel.com/content/www/us/en/content-details/778690/intel-ethernet-controller-products-release-notes.html) you get the 30.4 release notes, it lists 700 series and freeBSD 14.3 as supported. However, I downloaded the 30.4 bundle (900MB zip file) and I don't see x722 in it.
Note: The 30.4 doc mentions 700 series, no new NVM. NVM 6.5 is the latest and from what I can see, no changes to x722 between 30.1.0.1 and 30.4, other than 30.4 says freeBSD 14.3 is supported:
2.2 Intel® Ethernet 700 Series Network Adapters
2.2.1 Firmware/NVM/NVM Update
• None in this release
Note: The only "known issues" I see are notes around the 710, nothing for the x722.
Another oddity is, Intel docs are not 100%. Release notes list x722 as being in the Intel 30.1.0.1 download bundle, but when I open that bundle I don't find x722, I only see the 710 for 700 series.
bsd 14.3 reference: https://www.freebsd.org/releases/14.3R/announce/
Intel
https://www.intel.com/content/www/us/en/content-details/853125/intel-ethernet-controller-products-release-notes.html
30.1.0.1 bundle --> https://downloadmirror.intel.com/856143/Release__30.1.0.1.zip
30.4 bundle --> https://downloadmirror.intel.com/863589/Release_30.4.zip
Neither bundle has any x722 stuff, just 710. Makes me wonder if x722 is an integrator only item?
Also, Intel device ID 0x37d3 (dec 170) I can't find just yet. It's reporting vendor=0x8086 which is ID for Intel.
Your x722 is many/few revs behind.
You are currently at NVM 4.00 (software 23.4 or 23.5.2), which is just about dead middle of the Intel versions available.
The latest for x722 is from software 30.1.0.1 with NVM 6.50
Matrix here --> https://cdrdv2.intel.com/v1/dl/getContent/336882
In the features matrix you can see there's not much new from old stuff to new, mostly virtualization stuff. Well, it doesn't actually says if any issues for any feature was fixed, it's just a feature matrix, etc.
My guess is, the ixl kernel driver in freeBSD 14.3 should be ok, but it appears to not be validated by Intel (see notes about 30.4)
Upgrading NVM would be for two reasons:
1) needing a newer feature
2) possibly fixing issues (of which is not mentioned in the Intel doc)
For best possible function with less probability for errors, make sure the sfp's are "Intel validated".
See the bsd doc for ethernet/driver support --> https://www.freebsd.org/releases/14.3R/hardware/#ethernet
Since the bsd 14.3 doc does say ixl supports Intel 700 series, I think it's ok as long as the SFP's are Intel type, which your outputs appear to show.
The only caveat is, where did you get those Intel SFP's? Years ago I had issue with cisco switch gear that only played nice with real cisco SFP's, and the ones we got reported as "cisco" but were actual grayware that got into supply chain. Vendor got us new SFP's from another supply chain line and then all was good. This however was just turning up the SFP in a specific fiber mode.
All that said, the only eye-catcher
Is there something in the 14.3 ixl driver that is not playing nice with your older NVM? Possibly so. There's no matrix I can find that does back-versioning validation.
EDIT: So if you select latest release 30.4 and hit DOWNLOAD button (https://www.intel.com/content/www/us/en/content-details/778690/intel-ethernet-controller-products-release-notes.html) you get the 30.4 release notes, it lists 700 series and freeBSD 14.3 as supported. However, I downloaded the 30.4 bundle (900MB zip file) and I don't see x722 in it.
Note: The 30.4 doc mentions 700 series, no new NVM. NVM 6.5 is the latest and from what I can see, no changes to x722 between 30.1.0.1 and 30.4, other than 30.4 says freeBSD 14.3 is supported:
2.2 Intel® Ethernet 700 Series Network Adapters
2.2.1 Firmware/NVM/NVM Update
• None in this release
Note: The only "known issues" I see are notes around the 710, nothing for the x722.
Another oddity is, Intel docs are not 100%. Release notes list x722 as being in the Intel 30.1.0.1 download bundle, but when I open that bundle I don't find x722, I only see the 710 for 700 series.
bsd 14.3 reference: https://www.freebsd.org/releases/14.3R/announce/
Intel
https://www.intel.com/content/www/us/en/content-details/853125/intel-ethernet-controller-products-release-notes.html
30.1.0.1 bundle --> https://downloadmirror.intel.com/856143/Release__30.1.0.1.zip
30.4 bundle --> https://downloadmirror.intel.com/863589/Release_30.4.zip
Neither bundle has any x722 stuff, just 710. Makes me wonder if x722 is an integrator only item?
Also, Intel device ID 0x37d3 (dec 170) I can't find just yet. It's reporting vendor=0x8086 which is ID for Intel.
#52
General Discussion / Re: Limit Unifi Software Contr...
Last post by OPNenthu - Today at 05:34:27 AMFor convenience, I sometimes use the ShieldsUp! tool from GRC to initiate port scans on my public IP: https://www.grc.com/shieldsup
You can use the "User Specified Custom Port Probe" option to scan your ports 6789, 8080, 8443 and any others.
IMHO the self-hosted UniFi controller (especially with a local account) could be tamed even more for home internet users. It likes to send telemetry and usage data which is fine for organizations, but I don't want it on my private network. If you feel the same you can optionally add these to your DNS blocklist until such time that Ubiquiti gives us a proper way to disable it.
And yes, these domains are queried despite that I have the Analytics option unchecked in Settings. Apparently unchecking that only anonymizes the data, based on some Reddit reports. That unnecessarily sets up the conditions for a trust issue and I wish they would just fix it.
You can use the "User Specified Custom Port Probe" option to scan your ports 6789, 8080, 8443 and any others.
IMHO the self-hosted UniFi controller (especially with a local account) could be tamed even more for home internet users. It likes to send telemetry and usage data which is fine for organizations, but I don't want it on my private network. If you feel the same you can optionally add these to your DNS blocklist until such time that Ubiquiti gives us a proper way to disable it.
Code Select
trace.svc.ui.com
crash-report-service.svc.ui.com
And yes, these domains are queried despite that I have the Analytics option unchecked in Settings. Apparently unchecking that only anonymizes the data, based on some Reddit reports. That unnecessarily sets up the conditions for a trust issue and I wish they would just fix it.
#53
General Discussion / Failover WAN and wanting to ac...
Last post by plm - Today at 05:33:14 AMI've seen a number of examples of how to route traffic to a cable modem web UI when it's on a different subnet than the DHCP network it is providing, and that works fine for me.
The troube is, I have the same type of setup on my 5G failover modem, which I don't want to pass traffic across unless the cable modem circuit is down, and I'm struggling to find the right way to configure each of the interfaces so I can route traffic to the respective web UIs, but have the internet connection properly identified as up or down, and have the secondary link only pass any traffic in a failver scenario.
Does anyone have any posts, documentation, or other pointers I can look at for how to most effectively set this up?
Thanks.
The troube is, I have the same type of setup on my 5G failover modem, which I don't want to pass traffic across unless the cable modem circuit is down, and I'm struggling to find the right way to configure each of the interfaces so I can route traffic to the respective web UIs, but have the internet connection properly identified as up or down, and have the secondary link only pass any traffic in a failver scenario.
Does anyone have any posts, documentation, or other pointers I can look at for how to most effectively set this up?
Thanks.
#54
General Discussion / Re: Limit Unifi Software Contr...
Last post by Patrick M. Hausen - Today at 05:09:55 AMIf you run the scan from the internal network, you probably have that traffic allowed by rules on LAN. You need to scan from a host outside on the Internet to get a proper picture.
#55
General Discussion / Re: Losing WAN connection peri...
Last post by BrandyWine - Today at 04:49:18 AMQuote from: jstarta on September 02, 2025, 09:34:25 PMI've had 5 days uptime with zero problems since installing it as a VM (Under Proxmox), so it seems it's an issue with BSD drivers.Using the same hardware?
When did you get to the newer OPNsense 25.7.x (bsd 14.3) ?
Maybe there's a conflict between the bsd kernel driver and the controller firmware. Must be millions of devices running the Intel 226 running bsd 14.3 (guessing how many).
I don't recall in the thread, did you try an older version of OPNsense (https://docs.opnsense.org/releases.html)? This would have given you a definitive on if the bsd 14.3 with updated igc driver was the cause.
#56
25.1, 25.4 Series / Re: IPv6 not functional (Spect...
Last post by karvec - Today at 04:11:19 AMNo ISP provided equipment, just ISP <-> MB8600 cable modem <-> OPNsense box <-> various switches, APs, etc. Since I am really just troubleshooting the ISP <-> OPNsense I haven't focused on any of the LAN side of things... Figure when I get it working OPNsense <-> WAN I should be golden.
I believe it has worked in the past but I wasn't very interested in learning IPv6 then, or setting it up. I should have taken advantage of the learning experience when the opportunity was there, since it seems like it no longer is.
Thanks for your time and responses. If I manage to change something and it does start magically working I will definitely post my fix to this thread.
karvec
I believe it has worked in the past but I wasn't very interested in learning IPv6 then, or setting it up. I should have taken advantage of the learning experience when the opportunity was there, since it seems like it no longer is.
Thanks for your time and responses. If I manage to change something and it does start magically working I will definitely post my fix to this thread.
karvec
#57
General Discussion / Re: Limit Unifi Software Contr...
Last post by OmegaWaffle - Today at 03:47:44 AMQuote from: meyergru on September 02, 2025, 09:27:14 AMYou probably installed the Unifi Controller Plugin with a Unifi account instead of just a local account, which is encouraged by the workflow for the setup.
You are correct, I did set it up with a Unifi Account. I've deleted the plugin and started from scratch with a local account, along with tried to access my ip from a device completely unconnected to my network. It looks like I can no longer access the web UI, but when starting an nmap scan against my IP, I get open ports on 6789, 8080, and 8443. From what I can tell those are all used for Unifi equipment, so is there still accessible services on my network? Or am I misunderstanding the results of the nmap scan?
#58
General Discussion / Re: new install problem adding...
Last post by ldanna1945 - Today at 02:56:41 AMYes I figured it out. I missed the box to show community plug ins . So simple but I missed it. Thanks for listening.
LArry
LArry
#59
25.7 Series / Re: SOLVED - 25.7.2 shadowsock...
Last post by beren - Today at 02:47:09 AMWell, under the ShadowSocks: Local I have server address and port set, and local address 10.0.0.1 and local port 1080. I can see in the logs it's binding to 127.0.0.1 port 1080.
The server is set to 127.0.0.1 and port 8388.
I have not changed the config since it was working for the past couple years and use it with FoxyProxy on some of my machines.
I even checked the config.xml and it's correct. For now I was able to rig it to work with port forwarding but that's not ideal.
The server is set to 127.0.0.1 and port 8388.
I have not changed the config since it was working for the past couple years and use it with FoxyProxy on some of my machines.
I even checked the config.xml and it's correct. For now I was able to rig it to work with port forwarding but that's not ideal.
#60
General Discussion / Re: Firewall is blocking outbo...
Last post by shaam - Today at 02:13:20 AMYes, it's a physical device. It's a Dell PC, to be specific.
I am using Proxmox hypervisor.
I set a static IP on the VM itself.
Promox server has two interfaces, vmbr0 with subnet 192.168.1.1/24, which I use for management, the second interface, vmbr1 (for Proxmox) with subnet 192.168.50.1/24, which is a VLAN, is used by VMs and other external servers outside of Proxmox, such as Truenas, Backup server, etc. Traffic from VLAN to LAN gets blocked or vice versa.
I have a weird theory. It might have something to do with routing when VM 192.168.50.202 sends traffic to Proxmox (192.168.1.100) or any server on the LAN subnet, the packet goes from VM -> Opnsense-> Proxmox. Proxmox receives it on vmbr0. Proxmox replies to VM. Since Proxmox also has a direct connection to 192.168.50.0/24 (via vmbr1), it bypasses Opnsense and attempts to communicate directly with the VM. I might be wrong.
I am using Proxmox hypervisor.
I set a static IP on the VM itself.
Promox server has two interfaces, vmbr0 with subnet 192.168.1.1/24, which I use for management, the second interface, vmbr1 (for Proxmox) with subnet 192.168.50.1/24, which is a VLAN, is used by VMs and other external servers outside of Proxmox, such as Truenas, Backup server, etc. Traffic from VLAN to LAN gets blocked or vice versa.
I have a weird theory. It might have something to do with routing when VM 192.168.50.202 sends traffic to Proxmox (192.168.1.100) or any server on the LAN subnet, the packet goes from VM -> Opnsense-> Proxmox. Proxmox receives it on vmbr0. Proxmox replies to VM. Since Proxmox also has a direct connection to 192.168.50.0/24 (via vmbr1), it bypasses Opnsense and attempts to communicate directly with the VM. I might be wrong.
