Updated Realtek NIC drivers missing in PfSense 2.6.0
-
Well like I say drivers are especially required to match the kernel you're trying to load them into.
If you tried to manually load the kernel module I imagine the error would have been a kjernel mismatch.
Just use the pkg from our repo.
-
Thanks for your help. Obviously I don’t understand all the lingo but as I read the information on Freshports the 1.98 driver requires the newest port of FreeBSD?
I’m not sure what this means:
“To install the port: cd /usr/ports/net/realtek-re-kmod/ && make install clean”
Nor am I sure where I’d even run that. SSH?
-
There are no build tools in pfSense so you would need to build that in FreeBSD and then move the module or pkg. And that would be at the command line.
The 1.98 driver could be built against any FreeBSD version (within reason) but unless it has some particular update you need that 1.97 doesn't have I wouldn't bother. Except as an exercise perhaps.Steve
-
Thanks again. Now to try the Realtek 2.5gb cards again. Won’t have the space to do so until possibly tomorrow afternoon or Saturday.
Looked a little at the port thing. NOT going there.
A little confusing as to how some folks have 1.98 installed and working.
-
They are doing so in pfSense 2.6 for the most part. Let us know how the test goes.
-
@stephenw10 Sorta figured that but wasn't 100% sure. Which makes sense in a way with the wrong os warning. But I'm accessing the FreeBSD 14 folder. So that part is confusing. If the FreeBSD 12 folder? Okay, I'm trying to install the wrong build/port version. Maybe its not the FreeBSD 14 version in the folder and someone needs to address it? There are several flavors of 1.98 and maybe its not the "right" flavor?
Some dots are not connecting but not likely they're going to and I'm going to watch and wait because my guess is at some point 1.98 is going to work and install.
There's another piece to this Realtek 2.5gb attempt and thats main board architecture. The single port Intel i-225's, having seen any stand alone i-226's yet, are the smaller pci-e slot based cards. Used to be what I'd call pci-e "riser" slots. The dual i-225's are the longer pci-e slot like for video cards but not the longest PCI-e video card slot. Usually white where the very longest go back to black color.
Usually mother boards have just a few slots whether using a NIC or some other card. The real estate limits the options.
Unlike the Intel ones, the Realtek dual cards use the shortest pci-e slot architecture. IF they will work, opens up a few options for anyone with an older PC laying around that could be a PFSense router, has limited pci-e slots, and they need at least two 2.5gb ports. The need is increasing as more ISP's crank speeds up closer to 2gbs instead of 1.
I decided to use this older dell, it was free, because it has quite a few pci-e slots.
Won't be a big deal across the board but for some it'll matter and make their lives easier.
Since I'm already long winded here, I appreciate the work done to be able to have end users add the necessary drivers. Would not be a reasonable expectation on PFSense developers to make everything work out of the box. The way its worked out for the Realtek driver install is a very satisfactory middle ground.
-
The dual port 2.5gbe PCI-e card works great. Will gather a little more information and then do a separate post. My ISP depending on the day/time is 1.2gb or more. Even with other clients hanging on the PFSense box, using the Internet, another client connected to the second port of the NIC, I'm getting 1300-1400 on client connected through the Realtek.
That's pretty dang good.
Also do not have anything disabled in System Advanced Network. Its running with hardware checksum offload, Hardware TCP Segmentation Offloading and Hardware Large Receive Offloading all Enabled. The Intel cards never had any issues with those being enabled. Disabled to make sure the Realtek card would work. Re-enabled and they are fine.
The only frustrating thing is the way PFSense keeps track of the NIC's and the name/number and not the MAC. Pull or add a card, numbering scheme updates, assignments are goofed like for the bridge.
Would be nice if there was a way to keep those cards assigned by MAC and they'd stay in their lane even if a card is pulled or added. Not a deal breaker, just something have to anticipate but still....
re0: <Realtek PCIe 2.5GbE Family Controller>
re0: Using Memory Mapping!
re0: Using 1 MSI-X message
re0: version:1.97.00re1: <Realtek PCIe 2.5GbE Family Controller>
re1: Using Memory Mapping!
re1: Using 1 MSI-X message
re1: version:1.97.00 -
Currently the only thing you can do to keep the in the same order is to use PCI device wiring. However there is no scope for that within pfSense so reinstalling etc would lose anything you set.
There are a few open feature requests for interface numbering tracked by MAC but it's a non-trivial change.Steve
-
@stephenw10 It appears I can see some version reporting behavior from 23.01RC that @JimBob-Indiana also reported. The OS Boot logs don't seem to report driver version number for Realtek adapters after installing the realtek-re-kmod-198.00.pkg from https://pkg.freebsd.org/FreeBSD:14:amd64/latest/All/realtek-re-kmod-198.00.pkg
I proceeded to upload that realtek-re-kmod-198.00.pkg file to /tmp, and install it with the command pkg install -f -y /tmp/realtek-re-kmod-198.00.pkg
The /boot/loader.conf.local file remained intact with the correct entries.
Now the Status > System > Logs > System > OS Boot logs don't show any version numbers associated with re0 and re1. Not the built in driver of 197 (which did previously show in the OS Boot log), nor the newly installed 198 driver...
However...the system appears to work just fine.
Is there now a different command that would reveal the installed and executing driver version?
-
Try loading the realtek module manually from the command line, make sure it loads. It may be the kernel is mismatched sufficiently that the module refuses to load. It should report the version still AFAIK.
Is there something in 1.98 that you need? -
Yeah it won't load in 23.01-RC:
[23.01-RC][admin@6100.stevew.lan]/root: pkg add realtek-re-kmod-198.00.pkg Installing realtek-re-kmod-198.00... Newer FreeBSD version for package realtek-re-kmod: To ignore this error set IGNORE_OSVERSION=yes - package: 1400078 - running kernel: 1400073 Ignore the mismatch and continue? [y/N]: y Extracting realtek-re-kmod-198.00: 100% ===== Message from realtek-re-kmod-198.00: -- Add the following lines to your /boot/loader.conf to override the built-in FreeBSD re(4) driver. if_re_load="YES" if_re_name="/boot/modules/if_re.ko" By default, the size of allocated mbufs is enough to receive the largest Ethernet frame supported by the card. If your memory is highly fragmented, trying to allocate contiguous pages (more than 4096 bytes) may result in driver hangs. For this reason the value is tunable at boot time, e.g. if you don't need Jumbo frames you can lower the memory requirements and avoid this issue with: hw.re.max_rx_mbuf_sz="2048" [23.01-RC][admin@6100.stevew.lan]/root: kldload /boot/modules/if_re.ko kldload: an error occurred while loading module /boot/modules/if_re.ko. Please check dmesg(8) for more details.Because of the kernel version mismatch:
Feb 5 14:11:34 kernel KLD if_re.ko: depends on kernel - not available or version mismatch Feb 5 14:11:34 kernel linker_load_file: /boot/modules/if_re.ko - unsupported file type -
@stephenw10 unfortunately, I could not find any errata comparing 197 to 198, to know "officially" IF there was something updated that would be of value. So admittedly there is some (perhaps unfounded) trust that newer is better as it relates to Realtek ethernet driver adapters
I'm inferring you think that I should uninstall the 198 package? Would a package uninstall command in this instance be
pkg delete realtek-re-kmod-198.00.pkg
...and if I do that, should I reissue the command
pkg install realtek-re-kmod
...to bring the 197 "built in" driver back? OR...is there a better way to reinitialize the original "built in" 197 realtek driver package with ver 23.01RC?
-
You can just use:
[23.01-RC][admin@6100.stevew.lan]/root: pkg remove realtek-re-kmod Updating database digests format: 100% Checking integrity... done (0 conflicting) Deinstallation has been requested for the following 1 packages (of 0 packages in the universe): Installed packages to be REMOVED: realtek-re-kmod: 198.00 Number of packages to be removed: 1 Proceed with deinstalling packages? [y/N]: y [1/1] Deinstalling realtek-re-kmod-198.00... [1/1] Deleting files for realtek-re-kmod-198.00: 100%Then install the 1.97 pkg again.
-
Since Realtek don't seem to publish a change log we can't easily see what they added there. We'd have to just compare the source directly. But we can see the additional fixes in the kmod:
https://github.com/alexdupre/rtl_bsd_drv/commits/v1.98/if_re.c -
I also demonstrated 1.98 and the current FreeBSD 14 version of PFSense 2.7 don't get along. 1.97 works great. What's the difference between the drivers and if there's a reason we need 1.98 hard to tell given as just noted no way to easily compare 1.97 to 1.98. If "works" is all we need to decide, 1.97, 197.00, works great.
What does the OS Version mismatch actually mean though? Did not put a line in the 1.98 driver before its compiled that said, "These versions are okay to use...." so its only looking for one particular "build"? There's no build wiggle room so to speak?
There's a hook of some sorts in the latest FreeBSD build that 1.98 is looking for, "Look there's an open door...let's go inside..." that is not in the current FreeBSD 14 we're using for PFSense? "Look the door is closed, do NOT go in there...."?
The compiler used is different between the builds?
Is there something in the full version of FreeBSD for 1.98 to install that is missing in the version PFSense needs?
With Windows, I understand FreeBSD is not Windows, Windows as it gets updated while needing "new" drivers when we're talking major versions, like Windows 7 drivers/programs don't work in Windows 11, when we're talking same Windows version there's usually not an issue. Update Windows 11 for the most part does not equal previous Windows 11 drivers don't work.
FreeBSD 14 each build is a different beast?
From where I sit, and it is hardly from a position of knowing much about FreeBSD, seems like someone missed a line, messed up a punctuation entry, etc., when compiling 1.98. Part of reason I have that opinion is the thread on this very thing that indicates 1.98 is good to go with FreeBSD 14. It maybe on some versions of FreeBSD 14 but clearly not across the board.
This site: https://www.freshports.org/net/realtek-re-kmod/
Does the radioactive warning sign mean for 1.98 and FreeBSD 14 the 1.98 driver isn't even there yet?
My opinion is given how many threads one can find on Realtek drivers, a sticky of some sort with the steps that work for PFSense 2.7 would be beneficial. Folks like me chased our tail for some time before getting it sorted.
IF you haven't searched the great wide web for PFSense and Realtek Driver you don't quite understand the volume of "Here's the steps" posts there are.
-
@jsmiddleton4 said in Updated Realtek NIC drivers missing in PfSense 2.6.0:
Does the radioactive warning sign mean for 1.98 and FreeBSD 14 the 1.98 driver isn't even there yet?
It means the package doesn't exist in that branch. In this case where it doesn't exist is not surprising since 14:quarterly doesn't exist yet and the driver was likely never intended for those other architechtures.
Really I would say the surprising thing here is that the pkg/module does work in 2.6. Usually, for a kernel module, it can only be imported into the same kernel version it was compiled against. Which is what you see here.
-
I learned the hard way on this one...first, if you are running 2.6CE, you ONLY want to use the 197 driver.
First, if you intend to upgrade to 23.01RC, you had better be on ver 197, as 197 (as @stephenw10 has told us) is the built in driver for 23.01RC. It aids in making the upgrade path a tad easier.
I did have problems with a 2.6CE to 23.01RC upgrade...first, having to go to 22.01, then having to modify a /usr/local/share/pfSense/pkg/repos/pfSense-repo.conf file as the system would throw an "Unable to check for updates" error. Then I made the error of thinking the 198 package MUST be better than the 197 package, right? (wrong!).
So, as usual, best to follow @stephenw10 's advice, stick with the 197 package. I ended up having to go back to 2.6CE with the 197 driver just to claw my way back to a stable router.
I'm going to try out 23.01RC again...but not during the work week.
-
Technically the 1.98 kmod pkg has some additional fixes that are not in either the 1.97 or 1.98 driver directly. So it could be 'better'. But until we resync the tree with upstream again and pull that in it will be much easier to use 1.97. And 1.97 covers all hardware you're likely to find AFAIK.
Steve
-
Its okay if not but is there some notification when 1.98 could be an option?
Or is it up to us, again that's fine, to periodically check for package update?
-
There's nothing in pfSense that would alert you to that. You could write a script to do it.
Unless there is some proven significant advantage to 1.98 it's unlikely we would update it in the 23.01 repo. It will be pulled into 2.7 and 23.05 when we next upstream sync though.
Steve
