Messages

Well, the joy was shortlived. Im back at 100mbit full duplex now ...

This one says it can do crosstalk tests (but not sure what test for FEXT and NEXT). You can login to Amazon and use Rufus to post a question.
Amazon item B0DSHWHC7R "NOYAFA NF-8601S Network Cable Tester"

Another issue can be Alien Crosstalk, which is much harder to identify.

Crosstalk is an issue because it confuses the transceivers
https://www.flukenetworks.com/blog/cabling-chronicles/cable-testing-101-cross-talk-near-and-far

Thank you, i'll look into that.

Meanwhile, just yesterday, i updated my opnsense appliance to v26.1 , and lo and behold, my wan ethernet connection (between firewall and cablemodem) is up to 1gbs for more then a day now! What has been happening the last months is that it got to 1gbs after a reboot, and after a couple of hours reverted back to 100mbit.

I really hope this is permanent now, since i didnt change anything to my cabling, after the last time when i replaced a piece of cable (which tested ok afterwards) for a factory fresh premium cat7 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"?

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.

Can you point me in the right direction for such a cable tester? Which ones, brands , types etc?

Well, my new cable fix worked for a short time, only to just fall back to 100mbit full duplex. At that point, i felt beaten and didnt feel like pursueing this any longer, so i used my firewall with 100mbit spead instead of the 125mbit that my isp "gives" me.

Now i just upgraded to 25.7.11_1 and to my surprise, after a reboot, my wan port suddenly shows 1000mbit full duplex, and the various negitionable speeds are all shown for the nic. Will this again be a short lived joy or has there been any change in freebsd / opnsense regarding nic's? I searched but couldn't find any relevant information.

-edit: nevermind, it took les then 10 minutes for the wan interface to fallback to Ethernet autoselect (100baseTX <full-duplex>) 😓

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?

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"?

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.

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

Yes i used the Dell tool, booted windows to go and ran it on windows, but it gave me "update not available".

[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).

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.



-edit: my tinypic screenshot isn't loading, don't know how or why...

[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

hostb0@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

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:

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.

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:

# 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 website, it should be the i210-AT nic.

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:

[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.

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?

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?