re0 (Realtek) interface stays DOWN after upgrading to OPNsense 26.1.11_6 until m

[fengchen_opn]

re0 (Realtek) interface stays DOWN after upgrading to OPNsense 26.1.11_6 until manually brought up
After upgrading to OPNsense 26.1.11_6-amd64, my re0 (Realtek PCIe GbE Family Controller) interface does not come up correctly after boot.After bringing the interface back up manually, everything works normally.

Environment
OPNsense: 26.1.11_6-amd64
NIC: Realtek PCIe GbE Family Controller (re0)
Driver: os-realtek-re (installed)

[franco]

FWIW, the Realtek vendor driver was updated in 26.1.11: https://github.com/opnsense/ports/commit/a65b9e87

If it's the update then this may help:

# opnsense-revert -r 26.1.10 realtek-re-kmod


Cheers,
Franco

[fengchen_opn]

# opnsense-revert -r 26.1.10 realtek-re-kmod

Thank you, this fix worked.

[drosophila]

I also have Realteks and using the vendor drivers. In my case the system didn't shut down properly after the update was installed. It stopped responding completely and didn't even react to pressing NumLock, so the entire kernel was dead. There was exactly nothing on the console (blank screen with blinking cursor top left). After a hard reset it came up perfectly clean and things are working normally like nothing ever happened.

IDK why your realteks would not come up automatically, this might not be a driver issue but a configuration thing that may have surfaced now by chance? I had major stability issues with my Realteks until I applied a bunch of tunable tweaks, then there were performance issues requiring more tweaks, and the vendor driver was required for MSI to work reliably, luckily the MoBo Firmware also got an update because that, too, had MSI stability problems. But they always came up properly. They did go down under load without the tweaks, but came up by themselves afterwards (the network stack eventually would break if the cycle continued, though). It's a bunch of hassle, but maybe you might try a clean image, like writing a -nano to some USB key and pop that in just to check if this really is a driver issue?

Interestingly, the driver seems to have dropped all RTL84xx chips. It also mentions changes to flow control negotiation (this might be your problem? Might try hw.re.flow_control="0" as the driver suggests) and fixes to checksum offload for IPv6 (I still would disable it).

I had noticed the os-realtek being updated and sort of expected issues like this and it didn't fail to disappoint me. :) TBF, this kind of thing happens with other kernel modules as well on occasion, swapping out the innards of the kernel underneath the running kernel always is risky business. :)

A health audit came up clean:

***GOT REQUEST TO AUDIT HEALTH***
Currently running OPNsense 26.1.11_6 (amd64) at Wed Jul  8 14:51:27 CEST 2026
>>> Root file system: /dev/ufs/OPNsense_Nano
>>> Check installed kernel version
Version 26.1.11 is correct.
>>> Check for missing or altered kernel files
No problems detected.
>>> Check installed base version
Version 26.1.11 is correct.
>>> Check for missing or altered base files
No problems detected.
>>> Check installed repositories
OPNsense (Priority: 11)
>>> Check installed plugins
os-cpu-microcode-intel 1.1
os-ddclient 1.31_1
os-iperf 1.0_2
os-realtek-re 1.0
>>> Check locked packages
No locks found.
>>> Check for missing package dependencies
Checking all packages: .......... done
>>> Check for missing or altered package files
Checking all packages: .......... done
>>> Check for core packages consistency
Core package "opnsense" at 26.1.11_6 has 68 dependencies to check.
Checking packages: ..................................................................... done
***DONE***

So the update was bumpy but successful. I'll proceed to check/attempt the NAT migration now.

[fengchen_opn]

but maybe you might try a clean image,

I tried reinstalling; version 26.1.6 works fine, but things go wrong after upgrading to 26.1.11. Anyway, I'm planning to switch to an Intel network card —haha.

[franco]

If it's the vendor driver breaking their own cards on update I don't have high hopes they will fix it. The FreeBSD driver may still work (just uninstall the vendor driver plugin).


Cheers,
Franco