OPNsense Forum
Archive => 22.1 Legacy Series => Topic started by: daudo on January 30, 2022, 01:09:44 pm
-
Hi,
like some others, I have also been bitten by the realtek driver issue. Before upgrading to 22.1, I read the announcement that the vendor driver had been dropped in favor of the original FreeBSD variant and that I should have a look, if the FreeBSD driver supported my NIC. Here's what the release announcement says https://forum.opnsense.org/index.php?topic=26536.0:
The Realtek vendor driver is no longer bundled with the updated FreeBSD kernel. If unsure whether FreeBSD 13 supports your Realtek NIC please install the os-realtek-re plugin prior to upgrading to retain operability of your NICs.
And so I did, I verified that my NICs were supported by the vanilla FreeBSD driver and so I decided that using the os-realtek-re drivers was not necessary and instead I gave the FreeBSD drivers a try.
re0@pci0:2:0:0: class=0x020000 rev=0x0c hdr=0x00 vendor=0x10ec device=0x8168 subvendor=0x10ec subdevice=0x0123
vendor = 'Realtek Semiconductor Co., Ltd.'
device = 'RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller'
class = network
subclass = ethernet
re1@pci0:3:0:0: class=0x020000 rev=0x0c hdr=0x00 vendor=0x10ec device=0x8168 subvendor=0x10ec subdevice=0x0123
vendor = 'Realtek Semiconductor Co., Ltd.'
device = 'RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller'
class = network
subclass = ethernet
Unfortunately, like some others have noticed, too, the FreeBSD driver would work for a while but then just drop all connections, constantly toggling between UP to DOWN state.
So at least from my POV, it might be a good idea to tell people that checking if the vanilla FreeBSD realtek driver supports a NIC or not is not sufficient and that things may break randomly any time later.
And if I could choose, I'd rather stick with the os-realtek-re vendor driver for the time being, until it is clear, which NICs are not only (allegedly) supported but also known to be working with the vanilla FreeBSD driver.
-
Yes, just use the vendor driver like mentioned?
Cheers,
Franco
-
The issue is that the vanilla FreeBSD driver claims to support the devices. So if you go and check, things look fine at first when using with the FreeBSD driver and at least according to your release announcement, this should suffice.
But issues start to surface hours later, when you maybe have long left the physical site where the firewall is located, without the chance to intervene. So you need to go back and install the vendor driver (like I just had to do).
At least for my taste, this is a little bit too much trial and error for a production release.
-
Nobody ever claimed otherwise. That is WHY the driver exists and WHY it was included in OPNsense a long time ago so we do not have to have this irrelevant discussion about how unfair the world is.
Cheers,
Franco
-
LOL well then, if updates breaking production systems leads to irrelevant discussions about how unfair the word is, then so be it!
Really enjoying your professional tone! Enjoy your Sunday!
-
Being the professional network engineer you supposedly are, I am sure you read the release notes before upgrading a mission critical production system. And made sure everything works as intended doing an upgrade in a contained test environment first.
On the flip side major operating system changes bear risk for regression
and feature removal, e.g. no longer supporting insecure cryptography in
the kernel for IPsec and switching the Realtek vendor driver back to its
FreeBSD counterpart which does not yet support the newer 2.5G models.
https://opnsense.org/opnsense-22-1-released/
Also it is quite well documented that running Realtek with FreeBSD in production is asking for trouble.
-
daudo, it's pointless to blame authors of a free product provided with community support that level of support doesn't meet your expectations.
Do you need to have stable and deeply tested product? Need professional support?
OPNsense business edition is for you.
If you are earning any money with OPNsense it would be fair to share the profit with OPNsense authors.
Using OPNsense for yourself and still want to have deeply tested product? Then just wait a few days or weeks before switching to the next major version.
In any case, your negativity will not help anyone.
Note: I'm just an OPNsense user (and very minor contributor).
-
Isn't this blowing a bit out of proportion? :)
If I understand correctly, the OP simply suggested to make the wording in the release notes a bit more firm, i.e. along the lines of: "If a realtek NIC is used, install the driver before doing any update".
At least to me this doesn't seem like some unreasonable demand or blaming of the developers, but rather just a friendly suggestion to avoid more threads like this one. :)
-
Isn't this blowing a bit out of proportion? :)
If I understand correctly, the OP simply suggested to make the wording in the release notes a bit more firm, i.e. along the lines of: "If a realtek NIC is used, install the driver before doing any update".
At least to me this doesn't seem like some unreasonable demand or blaming of the developers, but rather just a friendly suggestion to avoid more threads like this one. :)
I think everybody understood that, but then the next guy comes around and goes "You idiots suggested installing the package and now my sh** went down for a whole work day. I uninstalled the package and now it works. Go change the wording!"
The wording is, in my opinion, pretty spot on. It more or less says YMMV, and it even says that if you are unsure, you should probably go with the package.
OP, i think we've all been in your shoes. Even if you've done nothing wrong, things go bad and you get the blame (or at least feel the stress), and that's frustrating as hell. But sadly, this can happen anywhere. Print Nightmare patches, anybody?
You can take this instance as a lesson learned. There are a couple of things you can do next time to avoid problems (though nothing is 100% safe). HA setup allows you to patch with a week inbetween, testing in a lab for a longer period would've helped spot the issue aswell. Buying official hardware and a business subscription makes failure less likely because the vendor does the testing for you. Or just leave things as they are and accept the risk, but you save a lot of time and money.
At the end of the day "shit happens". If you did your due diligence, don't let hindsight bias eat you up. You were there to fix the problem, that's what counts.
-
Isn't this blowing a bit out of proportion? :)
If I understand correctly, the OP simply suggested to make the wording in the release notes a bit more firm, i.e. along the lines of: "If a realtek NIC is used, install the driver before doing any update".
At least to me this doesn't seem like some unreasonable demand or blaming of the developers, but rather just a friendly suggestion to avoid more threads like this one. :)
I think everybody understood that, but then the next guy comes around and goes "You idiots suggested installing the package and now my sh** went down for a whole work day. I uninstalled the package and now it works. Go change the wording!"
The wording is, in my opinion, pretty spot on. It more or less says YMMV, and it even says that if you are unsure, you should probably go with the package.
OP, i think we've all been in your shoes. Even if you've done nothing wrong, things go bad and you get the blame (or at least feel the stress), and that's frustrating as hell. But sadly, this can happen anywhere. Print Nightmare patches, anybody?
You can take this instance as a lesson learned. There are a couple of things you can do next time to avoid problems (though nothing is 100% safe). HA setup allows you to patch with a week inbetween, testing in a lab for a longer period would've helped spot the issue aswell. Buying official hardware and a business subscription makes failure less likely because the vendor does the testing for you. Or just leave things as they are and accept the risk, but you save a lot of time and money.
At the end of the day "shit happens". If you did your due diligence, don't let hindsight bias eat you up. You were there to fix the problem, that's what counts.
Maybe take a coffee break, or even two or three. This is not what these forums where supposed for. Keep cool, stay focused. Don't see things nobody wrote.
-
If someone makes a vanilla installation of 22.1 and not upgrade, will he find os-realtek-re among the available plugins?
If yes, then I don't see a real problem.
-
If someone makes a vanilla installation of 22.1 and not upgrade, will he find os-realtek-re among the available plugins?
Of course.
-
Isn't this blowing a bit out of proportion? :)
If I understand correctly, the OP simply suggested to make the wording in the release notes a bit more firm, i.e. along the lines of: "If a realtek NIC is used, install the driver before doing any update".
At least to me this doesn't seem like some unreasonable demand or blaming of the developers, but rather just a friendly suggestion to avoid more threads like this one. :)
I think this perfectly describes my intention. The last thing I had in mind was to blame anyone for anything.
At least in my opinion, after following the release notes for the update, I lost connectivity to 3 boxes after a while.
The flow of events was this:
1. The 22.1 release notes state this: "If unsure whether FreeBSD 13 supports your Realtek NIC ..."
2. So, I checked with FreeBSD if it supports my Realtek NICs and yes, FreeBSD 13 claims to support them, and I was assured that the NICs would work in opnsense 22.1 then
3. upgraded to 22.1
4. tested connectivity and all looked nice, then upgraded two more boxes and left the location
5. after a couple of hours, box by updated box lost network connectivity
That's why I thought it might be a good idea to warn others more explicitly that checking with FreeBSD if the NICs are supported or not might not be enough.
Peace.
-
Sidenote1: it is always risky to deploy in the field in production environment brand new version of any system. If production environment is in remote location, the risk is even higher. Especially if the new version is a major bump.
It's always safer to use version released a few months ago as it has been already installed many times and most critical bugs are already identified (most probably).
Sidenote2: simple i210 and even i211 NICs are rock-solid stable compared to Realtek NICs.
Even Chinese-made cards with i211 in miniPCI-E or M.2 format work better than Realtek.
Realtek NICs are more or less stable with any OS (Windows/Linux/FreeBSD) with vendor drivers or with light load only.
-
Hi!
I am on
* OPNsense 21.7.7-amd64
and I am using a Realtek NIC.
After reading through this, I want to make sure I use download the os-realtek-re on beforehand.
How can I do this?
Trying to install via GUI gives me:
***GOT REQUEST TO INSTALL***
Installation out of date. The update to opnsense-21.7.8 is required.
***DONE***
:p
-
Update to 21.7.8 first?
Cheers,
Franco
-
I am on
* OPNsense 21.7.7-amd64
and I am using a Realtek NIC.
After reading through this, I want to make sure I use download the os-realtek-re on beforehand.
How can I do this?
Do installed plugins persist through updates?
-
Update to 21.7.8 first?
Cheers,
Franco
:P :P
Offcourse. My mistake, I did not read the update correctly. Somehow I thought pending updates was to version 22.1, but I see now 22.1 is only mentioned in the first line of the release notes and was not the actual update.
Thanks :) I'll try to update to 21.7.8 and then I'll try to install the plugin again before upgrading to 22.1.
-
I am on
* OPNsense 21.7.7-amd64
and I am using a Realtek NIC.
After reading through this, I want to make sure I use download the os-realtek-re on beforehand.
How can I do this?
Do installed plugins persist through updates?
Not sure, all my themes became disabled. Tho hardly mission critical
-
I am on
* OPNsense 21.7.7-amd64
and I am using a Realtek NIC.
After reading through this, I want to make sure I use download the os-realtek-re on beforehand.
How can I do this?
Do installed plugins persist through updates?
Not through major upgrades. Erratum: they should persist between upgrades.