I have a very simple setup which consists of a supermicro 1he appliance with intel nics running opnsense. It has an intel j1900 cpu.
I always run updates when they are released by opnsense and never had any issues, until now.
After updating to 25.7.2 my wan interface suddenly can't make an fysical network link to my cable modem. The link-led flashes on and of on my modem. When i fixate the speed to 100mbit fullduplex the link works again. But on autosense , which normally results in 1000base full duplex the link fails. I disabled all hardware offloading for the nic but that seemed to make no difference. In order to keep access to the internet i now have to run on 100mbit otherwise the link fails.
The nics in my appliance are two intel i210 nics, which until now never have gave my any problems. Can this please be fixed so that i can use full bandwith of my internet connection again?
I have what is probably a similar board - Supermicro X10SBA, J1900 with 2 Intel 210 NICs. I just did the upgrade to 25.7.2, and my NICs are both showing connection at 1 Gbps (the link indicator LEDs are glowing amber, which the user's manual says means 1 Gbps), and I am getting well over 100 Mbps even over an old wifi N connection. So I don't think there's anything inherent about the upgrade that would cause your issue. I'd look at configuration issues (start with factory defaults and see if that gets you full speed?) and maybe even a bad ethernet cable (I had one of those recently tie me to 100 Mbps). Good luck with your troubleshooting...
A new kernel was installed, but I don't suspect that's your issue.
I just went 25.7.1.x to 25.7.2, no issues.
I run one of the chinese N150 mini pc's that have intel 2.5G copper and two sfp+.
Pasting the notes for 25.7.2 here
QuoteHere are the full patch notes:
system: increase log file download timeout to prevent exit before data has returned
system: HTML decode entities when generating new QR code for user
system: add missing timestamp formatter in snapshots
system: prevent the root user from changing its name
interfaces: capture netmap ring when listening on interfaces in netmap mode
firewall: skip reply-to for inversion rules
firewall: remove unused "set loginterface" clause
firewall: additional statistics for alias grid
firewall: fix shaper reset button
captive portal: preparations for SSO identification support
dnsmasq: swap hosts and domains tab for consistency reasons
dnsmasq: allow disabling local for DHCP domains
firmware: abort on what appear to be partial updates due to obscure file errors
firmware: store update and upgrade logs in edge cases
firmware: opnsense-version: support file based -R option
firmware: opnsense-update: support -g for update log view
firmware: remove tier 2 workaround for Zenarmor plugins
firmware: add date to modal header
kea-dhcp: ignore encoding errors in lease parser
intrusion detection: fix and simplify grid search in download tab
ipsec: passthrough networks setting missed "allow new" flag
ipsec: add firewall rules skip option for VTIs
ipsec: deprecate legacy stroke and implement swanctl for overview
isc-dhcp: allow static mapping export for disabled entries
openvpn: add nopool directive
unbound: configurable top domain list length in reporting view (contributed by sopex)
unbound: remove unknown model reference and protect/simplify remaining one
wireguard: move backend scripts to proper location
backend: added IPv6 bracket helper for templates (contributed by BPplays)
lang: updates for Chinese, Czech, German and Greek
mvc: improve resilience of VPNIdField and LinkAddressField
mvc: repair side affect of getDescription() change causing performance regressions
mvc: modify existing and add missing descriptions in models
mvc: set default validation message for CertificateField
rc: make changes to php,var,tmp bootstrap
ui: fix language selection for low vertical resolution screens (contributed by sopex)
ui: hide header of the picture widget on the dashboard (contributed by sopex)
plugins: os-clamav 1.8.1[1]
plugins: os-crowdsec 1.0.12[2]
plugins: os-frr 1.46[3]
plugins: os-shadowsocks 1.2 switches to shadowsocks-rust
plugins: os-smart 2.4 adds extended info option (contributed by poisonbl)
plugins: os-telegraf 1.12.13[4]
plugins: os-theme-advanced updates logos (contributed by Raushan Patel)
src: route: fix "route -n monitor" when its output is redirected[5]
src: add a new sysctl in order to differentiate UEFI architectures[6]
src: libarchive: merge version 3.8.1[7]
src: lagg: fix if_hw_tsomax_update() not being called
src: wg: add support for removing allowed-ip entries and assorted cleanups
src: ovpn: support multihomed server configurations and assorted cleanups
src: netlink: fully clear parser state between messages
src: udp: fix a inpcb refcount leak in the tunnel receive path
src: p9fs: assorted fixes
ports: ca_root_nss / nss 3.115[8]
ports: krb5 1.22[9]
ports: libpfctl 0.16
ports: lighttpd 1.4.81[10]
ports: perl 5.40.3[11]
ports: php 8.3.24[12]
ports: py-jq 1.10.0[13]
Stay safe,
Your OPNsense team
Quote from: jjelliott on August 22, 2025, 02:17:28 AMt 1 Gbps (the link indicator LEDs are glowing amber, which the user's manual says means 1 Gbps),
You say it's 1G. Should it be different?
QuoteYou say it's 1G. Should it be different?
No, the OP said his links only worked at 100M, and my response was simply that mine are working at a higher speed than that. On an old wifi N laptop I'm getting about 160 Mbps, and the amber LEDs on the ports themselves indicate 1 Gbps connections. (The user manual for my board says if the connection were 100 Mbps, the LEDs would be green.)
Quote from: lebowski on August 21, 2025, 10:53:44 PMThe nics in my appliance are two intel i210 nics, which until now never have gave my any problems. Can this please be fixed so that i can use full bandwith of my internet connection again?
I would try to unplug and then plug in the network cable from both your OPNsense and the cable modem. If that does not fix it, then try with fully powering off (may need to unplug the power cable) both devices. If the SuperMicro does have an BMC module, wait for one or two minutes until it is fully off (NIC LED may be an indicator).
Hopefully this helps and the NIC will be able again to properly do autosense and sync with 100 Mbit/s.
I did unplug the ethernet cable from my cable modem. This resulted in having an 100mbit link (after i set the nic speed manually to 100mbit). On autosense , even after unplugging the cable, it keeps negotiating link speed, the green nic led keeps flashing on and of slowly, but there is no final link. I can't replace cables because my cablemodem and opnsense firewall are on different floors and i use fixed cables (cat6/7 pimf high quality shielded). I did power cycle the cable modem, i did reboot my opnsense appliance but did not give it a cold reboot.
It's ok for me to do a reinstall, it should be a nice oppurtunity to do a fresh install after years of updating existings installs, replacing its ssd at the same time. My only concern is that i use dnscrypt-proxy and i dont know how to backup the whitelist that i manually made. When i backup my current opnsense config and restore it to a new installation, will all this be reinstalled correctly in the new install, including the dnscrypt-proxy whitelist?
What about hard setting the iface? Sometime auto-neg no worky.
You said you set it manually to 100Mb, what about setting to 1G FD?
Quote from: lebowski on August 21, 2025, 10:53:44 PMWhen i fixate the speed to 100mbit fullduplex the link works again.
Daft as it may sound, have you tried a different network cable? Autonegotiation failures or inability to negotiate at 1000Mbps can often be associated with a cable going bad. The upgrade to 25.7.2 may just be a coincidence.
Quote from: hedders on August 23, 2025, 07:07:24 AMQuote from: lebowski on August 21, 2025, 10:53:44 PMWhen i fixate the speed to 100mbit fullduplex the link works again.
Daft as it may sound, have you tried a different network cable? Autonegotiation failures or inability to negotiate at 1000Mbps can often be associated with a cable going bad. The upgrade to 25.7.2 may just be a coincidence.
It would be very odd coincidence though. I think OP just did an upgrade from GUI, then link was bad, then messed around with the cable. So if it was good from the start then it should be good after the upgrade........ would be my expectation.
Maybe look at dmesg to see if there's any driver complaint. kldstat to see what's loaded now, etc. (your if driver may not be a klm, etc).
Also check if the proper driver is listed from kernel (the if_ items, etc), because there was a kernel update.
ls /boot/kernel | grep -v kernel
My ifconfig -a shows me "igc" for the coppers, so in kernel list i see "if_igc.ko", etc.
Sometimes its a cable, many times its the nic driver.
Quote from: hedders on August 23, 2025, 07:07:24 AMDaft as it may sound, have you tried a different network cable? Autonegotiation failures or inability to negotiate at 1000Mbps can often be associated with a cable going bad. The upgrade to 25.7.2 may just be a coincidence.
It only takes a break (or a stuck pin, or some dirt) in pins 4, 5, 7 or 8 and the connection willl never go above 100Mbps.
Changing the cable would always be my first check. A quick look in the two sockets with a torch would be my next quick check!
Quote from: tofflock on August 24, 2025, 12:00:43 AMQuote from: hedders on August 23, 2025, 07:07:24 AMDaft as it may sound, have you tried a different network cable? Autonegotiation failures or inability to negotiate at 1000Mbps can often be associated with a cable going bad. The upgrade to 25.7.2 may just be a coincidence.
It only takes a break (or a stuck pin, or some dirt) in pins 4, 5, 7 or 8 and the connection willl never go above 100Mbps.
Changing the cable would always be my first check. A quick look in the two sockets with a torch would be my next quick check!
Yes, the 1 Gbit/s does need all 8 wires in the cable to be fine. In case your Ethernet cable may have a sharp bend (or had one in the past) one of the wires in it could be partially or fully broken, which will give you loose connection and so the auto negotiation does fail.
It could be an issue with the network driver, but I don't think that this minor OPNsense update has any NIC driver updates, as the underlying FreeBSD did not have even a minor update (I think).
If you did not touch the system or cable during the update / reboot to 25.7.2, then some thermal issue cause from the update (e.g. higher CPU / Network traffic) could have caused that an already damaged cable now broke completely.
At least I would also try with a different Ethernet cable, and also check that the sockets on both ends do not have any dust in it and still look fine.
If I upgrade form the GUI sitting in my den and the fw is in the computer room, how would a cable suddenly go bad? Could it be just from the vibration of a reboot, maybe from the BIOS sound if turned on? It's not adding up for me, but try another cable since the original was already touched.
Well, i haven't sit still, tried a lot of things. I pulled my supermicro opnsense appliance from its rack, cleaned it, replaced it's ssd, noticed there was a bios firmware upgrade for the supermicro appliance so upgraded that too, did a complete fresh zfs reinstall of opnsense.
After that, pulled most network cables from their sockets going from and to the cablemodem and cleaned them with contact spray (i think this is called deoxit in the states), tried a different network cable going from cablemodem to the wall network socket (from there my wan cable goes to my rack which sits in my attick), and after all of this: still no luck. My wan interface only works if i put it on fixed 100mbit rate.
To clearify my situation: before and after updating to 25.7.2, i did nothing to my network cables, they all are nicely installed in regulation tubes in my walls, going from (shielded) socket to (shielded) socket. Never had any issues with these cables.
I also noticed i was previously running opnsense in bios csm mode, now i disabled all legacy stuff and are running in native uefi mode. Also changes nothing.
from dmesg:
Quote[1] igb0: <Intel(R) I210 (Copper)> port 0xd000-0xd01f mem 0x88900000-0x8897ffff,0x88980000-0x88983fff at device 0.0 on pci2
[1] igb0: EEPROM V3.16-0 eTrack 0x800004d9
[1] igb0: Using 1024 TX descriptors and 1024 RX descriptors
[1] igb0: Using 4 RX queues 4 TX queues
[1] igb0: Using MSI-X interrupts with 5 vectors
[1] igb0: Ethernet address: ##:##:##:##:##:##
[1] igb0: netmap queues/slots: TX 4/1024, RX 4/1024
Same goes for igb1
It appears that if_igc.ko is loaded.
Now i got this brilliant idea 😂 of placing a small ethernet switch inbetween the cablemodem and the network cable going to the firewall. Maybe this will help shed some light to the current situation. Haven't done it yet, but if it will result in a solid stable 1gbit link going all the way from my opnsense firewall to my cablemodem, then i would know that my opnsense box and the network cables arent the culprit. I didnt have the time to try it yet, but this will be my next "test". I have had some downtime from my isp recently where they where working on their network, and i want to rule out that they pushed a dodgy firmware to my cablemodem.
Your quote says igb
but you say igc is loaded ??
igb and igc are in the kernel build, so where are you seeing igc ?
igb should be the correct driver
(https://www.intel.com/content/www/us/en/support/articles/000005480/ethernet-products.html)
There's also a few flavors of the i210, might you what which flavor it is?
- Intel Ethernet Controller I210-AS
- Intel Ethernet Controller I210-IT
- Intel Ethernet Controller I210-CL
- Intel Ethernet Controller I210-AT
- Intel Ethernet Controller I210-IS
- Intel Ethernet Controller I210-CS
Can you also post a kldstat
and
dmesg |grep igb
I'm sorry, i'm a bit confused here. I'm not very familiar with *nix systems. I tried to follow up on @BrandyWine 's post, where he mentioned:
QuoteAlso check if the proper driver is listed from kernel (the if_ items, etc), because there was a kernel update.
ls /boot/kernel | grep -v kernel
My ifconfig -a shows me "igc" for the coppers, so in kernel list i see "if_igc.ko", etc.
So i did that, logged in with putty in my opnsense box, and ran ls /boot/kernel | grep -v kernel . After this, i got a long list of modules, where i found if_igb.ko and if_igc.ko . I'm actually not sure what i'm looking at .
After reading his remark for the thirtied time ;-) , i know understand the ifconfig -a remark, and yes, now i understand that the interface name was meant. In my case it is igb0 and igb1.
The result of kldstat is:
Quote# kldstat
Id Refs Address Size Name
1 56 0xffffffff80200000 216dad8 kernel
2 3 0xffffffff8236e000 908a0 pf.ko
3 1 0xffffffff823ff000 4be0 if_enc.ko
4 1 0xffffffff82404000 3c10 pflog.ko
5 1 0xffffffff82408000 5e9300 zfs.ko
6 1 0xffffffff829f2000 1e280 opensolaris.ko
7 1 0xffffffff82a11000 11a78 pfsync.ko
8 1 0xffffffff82a23000 16650 if_lagg.ko
9 2 0xffffffff82a3a000 3558 if_infiniband.ko
10 1 0xffffffff82a3e000 aa30 if_gre.ko
11 1 0xffffffff82a4a000 fb90 carp.ko
12 1 0xffffffff82a5a000 ed60 if_bridge.ko
13 2 0xffffffff82a69000 8990 bridgestp.ko
14 1 0xffffffff83710000 4250 ichsmb.ko
15 1 0xffffffff83715000 2178 smbus.ko
16 1 0xffffffff83718000 3360 uhid.ko
17 1 0xffffffff8371c000 3360 wmt.ko
18 1 0xffffffff83720000 4364 ums.ko
19 1 0xffffffff83725000 4850 nullfs.ko
20 1 0xffffffff8372a000 20f0 coretemp.ko
I don't know how to find out which flavour my i210 controller is without pulling the entire firewall out of the 19" rack. Is there an easier way to find out?
According to this (https://www.supermicro.com/en/products/motherboard/x10sba) website, it should be the i210-AT nic.
Try
grep igb /var/run/dmesg.boot
and
pciconf -lv
That should give you enough information to identify the exact model of your interfaces.
Quote[1] igb0: <Intel(R) I210 (Copper)> port 0xd000-0xd01f mem 0x88900000-0x8897ffff, 0x88980000-0x88983fff at device 0.0 on pci2
[1] igb0: EEPROM V3.16-0 eTrack 0x800004d9
[1] igb0: Using 1024 TX descriptors and 1024 RX descriptors
[1] igb0: Using 4 RX queues 4 TX queues
[1] igb0: Using MSI-X interrupts with 5 vectors
[1] igb0: Ethernet address: **:**:**:**:**:**
[1] igb0: netmap queues/slots: TX 4/1024, RX 4/1024
[1] igb1: <Intel(R) I210 (Copper)> port 0xc000-0xc01f mem 0x88700000-0x8877ffff, 0x88780000-0x88783fff at device 0.0 on pci5
[1] igb1: EEPROM V3.16-0 eTrack 0x800004d9
[1] igb1: Using 1024 TX descriptors and 1024 RX descriptors
[1] igb1: Using 4 RX queues 4 TX queues
[1] igb1: Using MSI-X interrupts with 5 vectors
[1] igb1: Ethernet address: **:**:**:**:**:**
[1] igb1: netmap queues/slots: TX 4/1024, RX 4/1024
[17] igb1: link state changed to UP
[29] igb1: link state changed to DOWN
[33] igb1: link state changed to UP
[548] igb1: link state changed to DOWN
[552] igb1: link state changed to UP
[1] igb0: <Intel(R) I210 (Copper)> port 0xd000-0xd01f mem 0x88900000-0x8897ffff, 0x88980000-0x88983fff at device 0.0 on pci2
[1] igb0: EEPROM V3.16-0 eTrack 0x800004d9
[1] igb0: Using 1024 TX descriptors and 1024 RX descriptors
[1] igb0: Using 4 RX queues 4 TX queues
[1] igb0: Using MSI-X interrupts with 5 vectors
[1] igb0: Ethernet address: **:**:**:**:**:**
[1] igb0: netmap queues/slots: TX 4/1024, RX 4/1024
[1] igb1: <Intel(R) I210 (Copper)> port 0xc000-0xc01f mem 0x88700000-0x8877ffff, 0x88780000-0x88783fff at device 0.0 on pci5
[1] igb1: EEPROM V3.16-0 eTrack 0x800004d9
[1] igb1: Using 1024 TX descriptors and 1024 RX descriptors
[1] igb1: Using 4 RX queues 4 TX queues
[1] igb1: Using MSI-X interrupts with 5 vectors
[1] igb1: Ethernet address: **:**:**:**:**:**
[1] igb1: netmap queues/slots: TX 4/1024, RX 4/1024
[17] igb1: link state changed to UP
[29] igb1: link state changed to DOWN
[32] igb1: link state changed to UP
[239] igb1: link state changed to DOWN
[243] igb1: link state changed to UP
[372] igb0: link state changed to UP
[386] igb0: link state changed to DOWN
[390] igb0: link state changed to UP
[485] igb0: link state changed to DOWN
[508] igb0: link state changed to UP
[515] igb0: link state changed to DOWN
[530] igb0: link state changed to UP
[533] igb0: link state changed to DOWN
[535] igb0: link state changed to UP
[674] igb0: link state changed to DOWN
[675] igb1: link state changed to DOWN
[680] igb1: link state changed to UP
[1] igb0: <Intel(R) I210 (Copper)> port 0xd000-0xd01f mem 0x88900000-0x8897ffff, 0x88980000-0x88983fff at device 0.0 on pci2
[1] igb0: EEPROM V3.16-0 eTrack 0x800004d9
[1] igb0: Using 1024 TX descriptors and 1024 RX descriptors
[1] igb0: Using 4 RX queues 4 TX queues
[1] igb0: Using MSI-X interrupts with 5 vectors
[1] igb0: Ethernet address: **:**:**:**:**:**
[1] igb0: netmap queues/slots: TX 4/1024, RX 4/1024
[1] igb1: <Intel(R) I210 (Copper)> port 0xc000-0xc01f mem 0x88700000-0x8877ffff, 0x88780000-0x88783fff at device 0.0 on pci5
[1] igb1: EEPROM V3.16-0 eTrack 0x800004d9
[1] igb1: Using 1024 TX descriptors and 1024 RX descriptors
[1] igb1: Using 4 RX queues 4 TX queues
[1] igb1: Using MSI-X interrupts with 5 vectors
[1] igb1: Ethernet address: **:**:**:**:**:**
[1] igb1: netmap queues/slots: TX 4/1024, RX 4/1024
[17] igb1: link state changed to UP
[29] igb1: link state changed to DOWN
[32] igb0: link state changed to UP
[33] igb1: link state changed to UP
[1] igb0: <Intel(R) I210 (Copper)> port 0xd000-0xd01f mem 0x88900000-0x8897ffff, 0x88980000-0x88983fff at device 0.0 on pci2
[1] igb0: EEPROM V3.16-0 eTrack 0x800004d9
[1] igb0: Using 1024 TX descriptors and 1024 RX descriptors
[1] igb0: Using 4 RX queues 4 TX queues
[1] igb0: Using MSI-X interrupts with 5 vectors
[1] igb0: Ethernet address: **:**:**:**:**:**
[1] igb0: netmap queues/slots: TX 4/1024, RX 4/1024
[1] igb1: <Intel(R) I210 (Copper)> port 0xc000-0xc01f mem 0x88700000-0x8877ffff, 0x88780000-0x88783fff at device 0.0 on pci5
[1] igb1: EEPROM V3.16-0 eTrack 0x800004d9
[1] igb1: Using 1024 TX descriptors and 1024 RX descriptors
[1] igb1: Using 4 RX queues 4 TX queues
[1] igb1: Using MSI-X interrupts with 5 vectors
[1] igb1: Ethernet address: **:**:**:**:**:**
[1] igb1: netmap queues/slots: TX 4/1024, RX 4/1024
Quotehostb0@pci0:0:0:0: class=0x060000 rev=0x0e hdr=0x00 vendor=0x8086 device=0x0f00 subvendor=0x15d9 subdevice=0x0816
vendor = 'Intel Corporation'
device = 'Atom Processor Z36xxx/Z37xxx Series SoC Transaction Register'
class = bridge
subclass = HOST-PCI
vgapci0@pci0:0:2:0: class=0x030000 rev=0x0e hdr=0x00 vendor=0x8086 device=0x0f31 subvendor=0x15d9 subdevice=0x0816
vendor = 'Intel Corporation'
device = 'Atom Processor Z36xxx/Z37xxx Series Graphics & Display'
class = display
subclass = VGA
ahci0@pci0:0:19:0: class=0x010601 rev=0x0e hdr=0x00 vendor=0x8086 device=0x0f23 subvendor=0x15d9 subdevice=0x0816
vendor = 'Intel Corporation'
device = 'Atom Processor E3800 Series SATA AHCI Controller'
class = mass storage
subclass = SATA
none0@pci0:0:26:0: class=0x108000 rev=0x0e hdr=0x00 vendor=0x8086 device=0x0f18 subvendor=0x15d9 subdevice=0x0816
vendor = 'Intel Corporation'
device = 'Atom Processor Z36xxx/Z37xxx Series Trusted Execution Engine'
class = encrypt/decrypt
pcib1@pci0:0:28:0: class=0x060400 rev=0x0e hdr=0x01 vendor=0x8086 device=0x0f48 subvendor=0x15d9 subdevice=0x0816
vendor = 'Intel Corporation'
device = 'Atom Processor E3800 Series PCI Express Root Port 1'
class = bridge
subclass = PCI-PCI
pcib2@pci0:0:28:2: class=0x060400 rev=0x0e hdr=0x01 vendor=0x8086 device=0x0f4c subvendor=0x15d9 subdevice=0x0816
vendor = 'Intel Corporation'
device = 'Atom Processor E3800 Series PCI Express Root Port 3'
class = bridge
subclass = PCI-PCI
pcib3@pci0:0:28:3: class=0x060400 rev=0x0e hdr=0x01 vendor=0x8086 device=0x0f4e subvendor=0x15d9 subdevice=0x0816
vendor = 'Intel Corporation'
device = 'Atom Processor E3800 Series PCI Express Root Port 4'
class = bridge
subclass = PCI-PCI
ehci0@pci0:0:29:0: class=0x0c0320 rev=0x0e hdr=0x00 vendor=0x8086 device=0x0f34 subvendor=0x15d9 subdevice=0x0816
vendor = 'Intel Corporation'
device = 'Atom Processor Z36xxx/Z37xxx Series USB EHCI'
class = serial bus
subclass = USB
isab0@pci0:0:31:0: class=0x060100 rev=0x0e hdr=0x00 vendor=0x8086 device=0x0f1c subvendor=0x15d9 subdevice=0x0816
vendor = 'Intel Corporation'
device = 'Atom Processor Z36xxx/Z37xxx Series Power Control Unit'
class = bridge
subclass = PCI-ISA
ichsmb0@pci0:0:31:3: class=0x0c0500 rev=0x0e hdr=0x00 vendor=0x8086 device=0x0f12 subvendor=0x15d9 subdevice=0x0816
vendor = 'Intel Corporation'
device = 'Atom Processor E3800/CE2700 Series SMBus Controller'
class = serial bus
subclass = SMBus
igb0@pci0:2:0:0: class=0x020000 rev=0x03 hdr=0x00 vendor=0x8086 device=0x1533 subvendor=0x15d9 subdevice=0x1533
vendor = 'Intel Corporation'
device = 'I210 Gigabit Network Connection'
class = network
subclass = ethernet
pcib4@pci0:3:0:0: class=0x060400 rev=0xab hdr=0x01 vendor=0x10b5 device=0x8605 subvendor=0x15d9 subdevice=0x0816
vendor = 'PLX Technology, Inc.'
device = 'PEX 8605 PCI Express 4-port Gen2 Switch'
class = bridge
subclass = PCI-PCI
pcib5@pci0:4:1:0: class=0x060400 rev=0xab hdr=0x01 vendor=0x10b5 device=0x8605 subvendor=0x15d9 subdevice=0x0816
vendor = 'PLX Technology, Inc.'
device = 'PEX 8605 PCI Express 4-port Gen2 Switch'
class = bridge
subclass = PCI-PCI
pcib6@pci0:4:2:0: class=0x060400 rev=0xab hdr=0x01 vendor=0x10b5 device=0x8605 subvendor=0x15d9 subdevice=0x0816
vendor = 'PLX Technology, Inc.'
device = 'PEX 8605 PCI Express 4-port Gen2 Switch'
class = bridge
subclass = PCI-PCI
pcib7@pci0:4:3:0: class=0x060400 rev=0xab hdr=0x01 vendor=0x10b5 device=0x8605 subvendor=0x15d9 subdevice=0x0816
vendor = 'PLX Technology, Inc.'
device = 'PEX 8605 PCI Express 4-port Gen2 Switch'
class = bridge
subclass = PCI-PCI
igb1@pci0:5:0:0: class=0x020000 rev=0x03 hdr=0x00 vendor=0x8086 device=0x1533 subvendor=0x15d9 subdevice=0x1533
vendor = 'Intel Corporation'
device = 'I210 Gigabit Network Connection'
class = network
subclass = ethernet
ahci1@pci0:7:0:0: class=0x010601 rev=0x11 hdr=0x00 vendor=0x1b4b device=0x9230 subvendor=0x1b4b subdevice=0x9230
vendor = 'Marvell Technology Group Ltd.'
device = '88SE9230 PCIe 2.0 x2 4-port SATA 6 Gb/s RAID Controller'
class = mass storage
subclass = SATA
Quote from: lebowski on August 29, 2025, 04:34:50 PMAccording to this (https://www.supermicro.com/en/products/motherboard/x10sba) website, it should be the i210-AT nic.
Quote from: lebowski on August 30, 2025, 12:38:39 AMigb1@pci0:5:0:0: class=0x020000 rev=0x03 hdr=0x00 vendor=0x8086 device=0x1533 subvendor=0x15d9 subdevice=0x1533
Quote from: lebowski on August 29, 2025, 04:34:50 PMls /boot/kernel | grep -v kernel . After this, i got a long list of modules, where i found if_igb.ko and if_igc.ko . I'm actually not sure what i'm looking at .
Kudos for you doing some digging.
The lastest driver for i210 is v5.19.4 from July 2025. I not sure when your OS (my version of freeBSD 14.3-RELEASE-p2) was compiled, can find that on freeBSD ste, but then need to know what i210 driver code version was compiled into the kernel.
That long list you asked about shows the driver tree that is compiled into the kernel. kldstat shows you the drivers that were loaded in manually ("dynamically").
Sometimes less can be easier on the eyes
pciconf -l
1 step further is we find the device ID and check that with intel docs (https://www.intel.com/content/dam/www/public/us/en/documents/faqs/ethernet-controller-i210-i211-faq.pdf?asset=9597&-907791053.1537776712&)
Is indeed the AT fully programmed flavor.
Issues with i210, makes me wonder if the firmware version in EEPROM is causing issue? Yours looks like v3.16, other sites seem to show v3.30 "fixing security issues".
Flashing the nic firmware is a bit tricky, perhaps too hard for most.
Just for reference:
https://www.intel.com/content/www/us/en/products/details/ethernet/gigabit-network-adapters/i210-server-adapters/resource.html
https://www.intel.com/content/www/us/en/support/articles/000005790/software/manageability-products.html
https://www.dell.com/support/home/en-us/drivers/driversdetails?driverid=5r8tk
https://github.com/dgrafe/i210-tools/tree/master/i210-flash
New stuff as of 7/2025
https://www.intel.com/content/www/us/en/products/sku/64400/intel-ethernet-controller-i210at/downloads.html
https://www.intel.com/content/www/us/en/download/14098/intel-network-adapter-driver-for-82575-6-82580-i350-and-i210-211-based-gigabit-network-connections-for-linux.html
QuoteThe Intel I210 Ethernet controller has updatable firmware that can enhance its features and fix issues. You can update the firmware using a utility provided by Intel, which typically involves downloading the firmware package and running it on your system.
Overview of Intel I210 EEPROM Firmware
The Intel I210 Ethernet Controller requires firmware updates to enhance functionality and fix issues. The firmware is stored in the EEPROM (Electrically Erasable Programmable Read-Only Memory) and can be updated using specific utilities.
Updating the Firmware
Supported Operating Systems
Windows
Linux
Update Process
Download the Firmware Update Utility:
For Windows, download the I210_NVMUpdatePackage_v2_00_Windows.exe.
For Linux, use the appropriate command-line tools.
Installation Steps:
Windows:
Run the downloaded executable as an administrator.
Follow the prompts to complete the update.
Linux:
Boot from a live USB (e.g., Ubuntu).
Install necessary packages:
sudo apt install gcc-12 linux-headers-$(uname -r) make ethtool
Use the bootutil command to flash the firmware.
Important Considerations
Ensure that the firmware version is compatible with your specific I210 model.
Back up existing configurations before proceeding with the update.
Be cautious, as improper updates can lead to bricking the device.
Features of the Firmware Update
Fixes security vulnerabilities.
Improves network stability and performance.
Unlocks new features for enhanced functionality.
By following the correct procedures, users can successfully update the Intel I210 EEPROM firmware to maintain optimal performance and security.
Quote from: BrandyWine on August 30, 2025, 07:05:24 AMmakes me wonder if the firmware version in EEPROM is causing issue? Yours looks like v3.16, other sites seem to show v3.30
This probably makes the most sense, considering OP is adamant the cable is good and it was just a upgrade & reboot scenario. I have seen this sort of issue on an HP backplane swap-out w/ HP-UX, but it was the other way around (backplane delivered newer firmware, OS was running older driver). Oddly it rendered as NIC-related latency issues. The infrastructure team had to bring in HP techs to diagnose.
Well, this was a LOT of work. Upgrading the firmware on linux was too hard, i didn't understand that. So i created a windows to go live usb stick (which took a LONG time), booted from it (which also took a LONG time), and started the windows firmware upgrade package.
And then.... nothing 😔. The tool showed my two i210-at nics, with the message that there werent any updates available. According to the tool, my nics are on fw 3.22 now.
What i did find was other folks asking for firmware for their intel nics on the intel boards, which then got replied by the intel folks by stating that for in order to get access to the firmware for a intel nic, you have to sign a NDA approval (!) to even get possibly access to the firmware. This is not a matter of just downloading the fw.
An other thing is that sometimes the hardware vendor for the appliance can provide nic firmwares, but in my case, there is no such update package on the supermicro website for my appliance, so that too is a dead end.
But today it seems is the day of miracles. Because i did not touch any network cable, i only tried updating the nic firmwares, but i did reboot the opnsense appliance a couple of times and now miraculously my wan port negotiated at 1000baset and my network internet throughput is passing the 100mbit mark again. My subscription is for 125/25 and my actual speed is now 128.2 / 25.78 . Nice. Let's hope and pray it stays this way.
(https://tinypic.host/images/2025/08/31/20250831_002105.md.jpg) (https://tinypic.host/image/20250831-002105.GAUwO)
-edit: my tinypic screenshot isn't loading, don't know how or why...
Quote from: lebowski on August 31, 2025, 01:16:17 AMWhat i did find was other folks asking for firmware for their intel nics on the intel boards, which then got replied by the intel folks by stating that for in order to get access to the firmware for a intel nic, you have to sign a NDA approval (!) to even get possibly access to the firmware. This is not a matter of just downloading the fw.
Yeah you would have to go back to SuperMicro. At least your not dealing with a Chinese device manufacturer who will never provide a firmware update ever. I'm kind of tired of the Chinese dumping for everything, literal garbage that just goes into my local landfill.
Quote from: lebowski on August 30, 2025, 12:38:39 AM[1] igb1: EEPROM V3.16-0 eTrack 0x800004d9
It's was on 3.22 now? Hmmm, that does not seem to align with your output post #17. Your EEPROM looks like 3.16, or it was.
Also, I do believe v3.30 or higher is available from somewhere.
Maybe the tool did do upgrade to 3.22. What does "dmesg | grep igb" show you now?
Also to note, integrator's like SM, Asrock, ASUS, HP Dell, etc etc etc, don't care to build firmware upgrades for flashable devices unless they really need to. Some like Dell and others will provide flash images when security issues demand it. Sometimes the integrator builds the firmware to suit their needs or restrictions, other times a device manufacturer has full-featured firmware. As example, some years ago I had a DVD-rw drive in my PC, but the model I had could not rw Blueray. Well, turns out it was only firmware change that was needed, I exported my existing firmware and applied a mod, now it can rw blueray (had to do it this way because the firmware is very specific to some things in the drive). The maker of dvd drive sells the blueray-enabled device for more money, same drive, different words on the box, different firmware.
The fun world of firmware and drivers.
Was it the Dell tool you used? Their download for a "v3.30" looks like i210 tool + firmware.
https://www.dell.com/support/home/en-us/drivers/driversdetails?driverid=5r8tk
Quote from: BrandyWine on August 31, 2025, 06:06:15 AMQuote from: lebowski on August 30, 2025, 12:38:39 AM[1] igb1: EEPROM V3.16-0 eTrack 0x800004d9
It's was on 3.22 now? Hmmm, that does not seem to align with your output post #17. Your EEPROM looks like 3.16, or it was.
Also, I do believe v3.30 or higher is available from somewhere.
Maybe the tool did do upgrade to 3.22. What does "dmesg | grep igb" show you now?
Also to note, integrator's like SM, Asrock, ASUS, HP Dell, etc etc etc, don't care to build firmware upgrades for flashable devices unless they really need to. Some like Dell and others will provide flash images when security issues demand it. Sometimes the integrator builds the firmware to suit their needs or restrictions, other times a device manufacturer has full-featured firmware. As example, some years ago I had a DVD-rw drive in my PC, but the model I had could not rw Blueray. Well, turns out it was only firmware change that was needed, I exported my existing firmware and applied a mod, now it can rw blueray (had to do it this way because the firmware is very specific to some things in the drive). The maker of dvd drive sells the blueray-enabled device for more money, same drive, different words on the box, different firmware.
The fun world of firmware and drivers.
Yes it was on 3.22 . The screenshot which i made (and failed to upload) shows 3.22 being the decimal version, and 3.16 the hex version. This is a bit confusing. The tool showed for both nics "Status: update not available". And then "Tool execution completed with the following status: Device not found." (although before this sentence it shows the both i210 nics).
Quote from: BrandyWine on August 31, 2025, 05:11:50 PMWas it the Dell tool you used? Their download for a "v3.30" looks like i210 tool + firmware.
https://www.dell.com/support/home/en-us/drivers/driversdetails?driverid=5r8tk
Yes i used the Dell tool, booted windows to go and ran it on windows, but it gave me "update not available".
Quote from: lebowski on August 31, 2025, 06:42:37 PM3.22 being the decimal version, and 3.16 the hex version.
Does appear to be coincidence that 22 is 16 in hex.
EEPROM V3.16-0 eTrack 0x800004d9
I suspect it's just decimal.
How would they print 3.30, "3.1E" ? And then the -0, so it would print "3.1E-0" ?
Some more recent Intel stuff, i210 is in this bundle.
When you get the 800MB zip, there's a NVM flashing folder, has the tool and bin files for each OS.
i210 bin files are dated July 2021 though, but maybe it's better to have Intel firmware vs some unknown firmware that was flashed in by chinese maker of the device. ;)
I use 7zip to open the big zip file.
(https://i.postimg.cc/7ZkX1jst/Screenshot-2025-08-31-171813.png)
https://downloadmirror.intel.com/863589/readme.txt
https://www.intel.com/content/www/us/en/content-details/778690/intel-ethernet-controller-products-release-notes.html?DocID=778690
https://www.intel.com/content/www/us/en/download/15084/intel-ethernet-adapter-complete-driver-pack.html
Well, another day, new "adventures". I woke up today with no internet connection. Where i yesterday had a perfectly good working 1gb link between my opnsense appliance and my cablemodem, today i got nothing, not even 10mbit. So i dug a little further, and placed a small switch at my cablemodem between the network cables. It should be so that i got a solid link on the switch, but to my big surprise the link going all the way from my cablemodem to my opnsense box in my attick gave the exact same problems, not being able to make a link between devices. So i was shocked because that meant there was something wrong with my cabling OR my NIC. So i went upstairs to the attick, just randomly pulled the network cable going from my appliance to my network wall socket, replaced it with a factory made cable, and i immediately got a 1gb link! Hurray!
Now lets hope it indeed was that stupid(!) cable and from now on everything will work as it always have been.
Keep you posted.
It's the cable. ;)
I feel pretty stupid. And to think that, at the time when i installed all this cabling, i invested in premium cables, cat7 sftp pimf with shielded connectors, made everything by hand, pulled parts of the cable through cableducts in my walls, used premium shielded cat6 wall sockets, because i wanted to make sure.... THIS wouldn't happen. And yet it did. And i have to say, the cable that probably was causing issues, i can't see anything wrong with it, it just doesnt work. So now, to be extra sure, i placed a temporary cable which soon will be replaced by a brand new factory made cat7 sftp pimf cable (has been ordered, is on it's way). I don't want to have this misery again.
I yet have to check the link you send me for the 700mb archive in the previous post. Do you think it still would be a good idea to try and update firmware for my i210-at controllers? Or is it as they say: "if it works, don't touch it"?
Quote from: lebowski on September 04, 2025, 12:29:53 AMI feel pretty stupid. And to think that, at the time when i installed all this cabling, i invested in premium cables, cat7 sftp pimf with shielded connectors, made everything by hand, pulled parts of the cable through cableducts in my walls, used premium shielded cat6 wall sockets, because i wanted to make sure.... THIS wouldn't happen. And yet it did. And i have to say, the cable that probably was causing issues, i can't see anything wrong with it, it just doesnt work. So now, to be extra sure, i placed a temporary cable which soon will be replaced by a brand new factory made cat7 sftp pimf cable (has been ordered, is on it's way). I don't want to have this misery again.
I yet have to check the link you send me for the 700mb archive in the previous post. Do you think it still would be a good idea to try and update firmware for my i210-at controllers? Or is it as they say: "if it works, don't touch it"?
You need a cable tester that can do near/far x-talk testing, continuity tests, etc.
As for i210 NVM updating? It's like many warnings that come with updates, "if you are not trying to fix a specific issue.....".
Can the update make things better? Possibly. I just not sure what metrics you would be measuring. I also lean on the other side of that fence, if they made a new NVM image then why did they make it, they didn't do the effort just for fun, etc.
I also am wary of the china made stuff, the maker of the device could have loaded in their own NVM image, and nobody really knows what that code is. I think the NVM loader tool allows you to extract out a copy of the EEPROM code, from there you could look at it in hex editor or some diff tools to see if it's real Intel code or has been modified (comparing same NVM versions as example). From what I have seen, the bin files are highly padded, way more EEPROM space than actual code, so this gives plenty of room to place more code into the bin and load it in.
This is a big battle for say OPNsense who tries to help support via community forums. Unvalidated hardware is a nightmare to deal with, and here we have a gazillion people using all sorts of hardware along with VM's, and then everyone comes here to complain. If "you" want validation then buy an official OPNsense device. It's that simple.
All that said, I guess the community tries to help the community, but many don't have the skillset to dive in and look around and then fix when fixing is needed.
I completely agree about the cheap chinsese stuff; let alone being it a possible fire hazard, one does not know which code has been "programmed" in it's various firmwares. This is why i'm so happy with my us made supermicro appliance. I'm wondering myself if i should go ahead and update the nic's firmwares. As you said, they don't release firmware updates for nothing. On the other hand, a professional brand like supermicro would release these firmware update packages when it would be needed i guess. I'm a novice in this, but i guess they know what they're doing? And there isn't an update package for my appliance, which makes me wonder if there is anything to gain except a nasty brick of my nics making my beautiful appliance unuseable.
About fixing stuff: i'm no *nix expert. The great thing about opnsense in my opinion is that it is usable for novice/medium experienced users, not only hardcore network engineers, in contrary to (for example) mikrotik, which can't be used if your not some toughguy network engineer (is my experience). Opnsense gives you the robustness of a bsd operating system and the user friendlyness of a "working out of the box" product.
I think i will contact supermicro and ask them how they feel about updating their nics on my appliance. Maybe they have a custom build update package for internal use, which they care to share?
Quote from: lebowski on August 31, 2025, 06:42:37 PMQuote from: BrandyWine on August 31, 2025, 06:06:15 AMQuote from: lebowski on August 30, 2025, 12:38:39 AM[1] igb1: EEPROM V3.16-0 eTrack 0x800004d9
It's was on 3.22 now? Hmmm, that does not seem to align with your output post #17. Your EEPROM looks like 3.16, or it was.
Also, I do believe v3.30 or higher is available from somewhere.
Maybe the tool did do upgrade to 3.22. What does "dmesg | grep igb" show you now?
Also to note, integrator's like SM, Asrock, ASUS, HP Dell, etc etc etc, don't care to build firmware upgrades for flashable devices unless they really need to. Some like Dell and others will provide flash images when security issues demand it. Sometimes the integrator builds the firmware to suit their needs or restrictions, other times a device manufacturer has full-featured firmware. As example, some years ago I had a DVD-rw drive in my PC, but the model I had could not rw Blueray. Well, turns out it was only firmware change that was needed, I exported my existing firmware and applied a mod, now it can rw blueray (had to do it this way because the firmware is very specific to some things in the drive). The maker of dvd drive sells the blueray-enabled device for more money, same drive, different words on the box, different firmware.
The fun world of firmware and drivers.
Yes it was on 3.22 . The screenshot which i made (and failed to upload) shows 3.22 being the decimal version, and 3.16 the hex version. This is a bit confusing. The tool showed for both nics "Status: update not available". And then "Tool execution completed with the following status: Device not found." (although before this sentence it shows the both i210 nics).
I perhaps am wrong, and you are right.
I ran the nvmupdate64e to get inventory, and it shows my NVM for i226 as
"NVM Version : 2.23(2.17)"
23dec = 17hex
I do now notice the NVM bin files are named using the hex value.