Solved Network adapter issues.

Hello, Gang:

First, due to going through medical hell since January 2021, I have not been active on this forum for some time now. And secondly, due to the foregoing, I have forgotten several matters having to do with FreeBSD, which I had installed on my office desktop.

Then, a couple of months ago, the motherboard in my office desktop up and died on me: it slowly stopped recognizing its SATA ports, one by one, until it could no longer see any of them. So.....I replaced the motherboard and CPU with a new, much more capable one and essentially rebuilt the hardware in that desktop, keeping the HDDs.

The new mobo is an Asus STRIX Z690A WIFI D4, now with 16 GB RAM.

I did not reinstall Win10, simply changing it so that it was "moved over" to the new mobo. Win10 works fine....well...at least as well as it ever did, anyway.

I had installed FreebSD ver 13-RELEASE-XX on a second HDD with the old mobo, and it took some playing around to get the new mobo to allow me to boot on that drive, but I finally succeeded. FreeBSD runs quite well, with one exception: it does not recognize nor activate the network adapter.

After checking the system in Win10, I find the following network adapters attached to that system:

Product Type Realtek PCIe GbE Family Controller

Product Type Intel(R) Ethernet Controller (3) I225-V

Product Type Intel(R) Wi-Fi 6 AX201 160MHz

Name D-Link AirPlus DWL-G520 Wireless PCI Adapter(rev.B)

I found and downloaded the FreeBSD drivers for all of the above, and extracted them all to my FreeBSD installation. There was a README file included with the Realtek driver:

Here it is:
=================================================================================
= Realtek 8169S/8169SB/8169SC/8168B/8168C/8168CP/8168D/8168DP/8168E/8168F =
= 8168FB/8168G/818GU/8168H/8168EP/8411/8168FP =
= 8101E/8102E/8103E/8401/8105E/8106E/8402 =
= 8125 Driver =
= for FreeBSD v4.x/5.x/6.x/7.x/8.x/9.x/10.x/11.x//12.x/13.x =
=================================================================================

This driver is modified by Realtek Semiconductor corp. and it has been tested OK
on FreeBSD v5.4, FreeBSD v6.4, FreeBSD v7.3, FreeBSD v8.0, and FreeBSD v9.0. To
update the driver, you may use method 1. If method 1 failed, you must use method 2
which is more complex.

Method 1:
1.Copy if_re.ko in "modules" directory to "/modules" directory and overwrite
the existing file.
2.Modify the file "/boot/defaults/loader.conf" and set "if_re_load" in "Network drivers" section to "Yes"
3.Reboot.

Method 2:
Because the FreeBSD kernel has default drivers to support RTL8139C and RTL8169S. To use the RTL8139C+, RTL8169SB, RTL8169SC, RTL8168B, and RTL8101E, you need to update your NIC driver by recompiling your FreeBSD kernel.

The main steps you have to do:(FreeBSDSrcDir means the directory of FreeBSD source code
and it may be "/usr/src/sys")

1. keep the orginal driver source code:
# cd /usr/src/sys/dev/re
# cp if_re.c if_re.c.org

# cd /usr/src/sys/modules
# cp Makefile Makefile.org

# cd /usr/src/sys/modules/re
# cp Makefile Makefile.org

# cd /usr/src/sys/i386/conf/
# cp GENERIC GENERIC.org

2. recompile your kernel (you must install your FreeBSD source code first !!)
# vim /usr/src/sys/i386/conf/GENERIC and delete re
# vim /usr/src/sys/modules/Makefile and delete re
# cd /usr/src/sys/i386/conf
# /usr/sbin/config GENERIC

(for FreeBSD 5.x/6.x/7.x/8.x/9.x)
# cd ../compile/GENERIC
(for FreeBSD 4.x)
# cd ../../compile/GENERIC

# make clean
# make depend
# make
# make install
# reboot

3. update the driver source code:
Copy the driver source code( if_re.c and if_rereg.h) into /usr/src/sys/dev/re
Copy the Makefile into /usr/src/sys/modules/re

4. build the driver:
# cd /usr/src/sys/modules/re
# make clean
# make

5. install the driver
(for FreeBSD 12 or later)
# cd /usr/obj/usr/src/<arch>.<arch>/sys/modules
# kldload ./if_re.ko
(for FreeBSD 11 or earlier)
# cd /usr/src/sys/modules/re

# kldload ./if_re.ko

6. configurate the static IP address
# ifconfig re0 xxx.xxx.xxx.xxx

7. configurate the IP address by DHCP
# /sbin/dhclient re0

The user can use the following command to change link speed and duplexmode.
1. For auto negotiation,
#ifconfig re<device_num> media autoselect

2. For 1000Mbps full-duplex,
#ifconfig re<device_num> media 1000baseTX mediaopt full-duplex

3. For 100Mbps full-duplex,
#ifconfig re<device_num> media 100baseTX mediaopt full-duplex

4. For 100Mbps half-duplex,
#ifconfig re<device_num> media 100baseTX -mediaopt full-duplex

5. For 10Mbps full-duplex,
#ifconfig re<device_num> media 10baseT/UTP mediaopt full-duplex

6. For 10Mbps half-duplex,
#ifconfig re<device_num> media 10baseT/UTP -mediaopt full-duplex
_________________________________________________________________________________________________________________________

I attempted to use their Method 1, but couldn't find the file if_re.ko anywhere on my FreeBSD system, even after searching for it with find / -name "if_re.ko"

I DID find a file if_re.c , which I first copied out to a directory I saved, and copied the file if_re.c which was included with the driver file I got from Realtek, then rebooted, but no joy.

Since what I tried did not work, I most certainly am not going to try their Method 2 at this point.

Might anyone here have any ideas about how I can activate any of my network adapters?

Ken Gordon
 
OK. Some more info: dmesg -a comes up with all kinds of info. For one thing, it shows something like "link up lo0". First of all, I don't know what is lo0?

Should I post the entire output of dmesg -a here or just the "high-lights"? What "high-lights"?

It also is telling me that Windows is hibernating. I had no idea that FreeBSD even gave a royal damn about Windows. So, what does THIS mean? And am I on the wrong part of the forum?

If so, where should I post this question?

Ken Gordon
 
We need to know the Ethernet chipset in order to understand what drivers are required. The output from dmesg(8) would be fine.

However, I see that you have an Intel I225-V wired Ethernet adapter. I know that's not supported on FreeBSD 13.0, but is on 13.1.

So I suggest you upgrade to FreeBSD 13.1 and see what happens.
 
OK. Thanks. I discovered that lo0 is, of course, the loopback local, so I can ignore that for the present. I should have figured that out on my own. (Gee...after all I just turned 80 years old on April 23).

In order to upgrade my present FreeBSD, I need a working LAN (although I COULD do it from a DVD, I suppose), so, I'll install a spare Intel LAN card I have here, then go from there.

Thanks again,

Ken Gordon W7EKB
 
I am STILL curious as heck why my FreeBSD is complaining about Windows hibernating. I'll post the output of dmesg -a asap

Ken
 
Well, my idea of installing an extra NIC I have here didn't work. I installed an Intel C T Desktop Gigabit NIC, which I suspect is also not supported by my version of FreeBSD. OK. On to USB install of 13.1. Thanks again, gang.

Ken Gordon
 
Intel CT desktop adapter should absolutely work on FreeBSD.
What is the issue? DHCP problem or device not recognized at all?
i225-V is newer and problematic.
 
Try another PCIe slot if possible. That card is in the sweet spot and should work.
It doesn't show up in pciconf -lv at all?
 
I suspect the card, although being brand-new, is defective. I tried it within Win10, and it was acting very intermittent. I tried to use it to download a FreeBSD 13.1 image file while in Win10, and that download failed several times, and those few times it would download even part of the file, it would start out fairly fast, then drop to something like 140 kB/s, then would quit.

When I then disconnected the net cable from that NIC and plugged the cable back into the on-board NIC, the i225-V, the needed file downloaded in seconds.

I have one more new NIC that I will try tomorrow.

The mobo has one more PCI slot, a full-length one. This CT NIC has one of those very short connectors on the bottom, not a full-length one.

Again, thanks for the help and suggestions. I'll get it fixed yet.

Ken Gordon
 

SirDice

Administrator
Staff member
Administrator
Moderator
The mobo has one more PCI slot, a full-length one.
PCI slots have only one length. You're probably referring to PCIe x16 slot. PCIe slots can come in different sizes, x1, x4, x8 and x16. It should be fine to stick a smaller card (x1, x4) in a larger slot (x16).

The Intel I-225 (onboard?) network card should be supported by FreeBSD 13.1. Same for the Intel Wifi 6. Support for it was added in 13.1. Anything lower (13.0 or 12.x) will not support the I-225 or the Intel Wifi 6.

I have a system with an Asus Prime Z590-A, it has an Intel I-225 ethernet onboard. It works just fine with 13.1.
 
Thank you. I never got into the PCIe differences, but I assumed (bad idea?) that one could install the PCIe cards into the PCI slot, but never had an occasion to try it before now.

OK. Upgrading to 13.1 is the next step.

Ken Gordon
 

SirDice

Administrator
Staff member
Administrator
Moderator
but I assumed (bad idea?) that one could install the PCIe cards into the PCI slot
No, that's not going to work. PCI has a parallel bus (all data 'bits' have their own signal line). PCIe uses a serial communication protocol, each 'lane' is a separate serial connection. So an x1 will only use a single 'lane', x4 uses 4 lanes, x8 has 8 lanes, etc.

In this respect it's somewhat like SCSI and SAS. Both are SCSI, but the original SCSI used a parallel bus whereas SAS uses a serial bus. It's kind of odd, for quite some time transfer speeds were increased by widening the databus (8 -> 16 -> 32) and 'serial' was considered slow. Nowadays everything is pushed over serial connections at much greater speeds than was possible with the parallel buses. Oh well.
 
I am STILL curious as heck why my FreeBSD is complaining about Windows hibernating.
When Windows is hibernating, it saves the state of Windows and all peripherals a a file (or partition, I don't care about the details of that). Windows also expects to be alone on the machine - meaning peripherals will be in the same state when Windows resumes as when it hibernated. If you want, you can say that Windows "cheats" when initializing peripherals (pci cards, usb controllers, etc.) because it knows it is the only operating system on the machine.

To avoid trouble when using dual / multiple boot with Windows and other operating systems (FreeBSD), make sure that you shut down Windows every time, never let it hibernate.

FreeBSD detects the active hibernation file / partition and simply warns you about it.
 
OK. Thanks. Makes sense, too. I REALLY don't like Windows. Which is why I am working to dump Windows from all our computers (6) here.

On to the next issue(s): so, I have one PCIe network adapter installed, an old Intel CT gigabit NIC, model number 82574L, and an onboard network controller, an Intel I225-V. I have toddled off to Intel's site and downloaded what purports to be the correct tarred drivers for both for FreeBSD. (It is somewhat nice of Intel to support FreeBSD.)

However, when I attempt to follow Intel's directions to install the drivers, I must not be interpreting those somewhat arcane directions, since they don't make clear sense to me.

For instance, it tells me to untar the archive tar xfz ixgb-x.x.x.tar.gz, yet there IS no ixgb file anywhere in the tarball. There is an ixl, though, and an ice.

Until I can translate the above into something I can understand, I am stuck for the moment.

Secondly, Intel tells me that my old CT NIC has been discontinued, which is fine with me, although I have yet to find any driver on their site which directly mentions the 82574L card or what it is derived from.

I am sort of hoping that FreeBSD has either or both of those drivers stored away somewhere, but have yet to find those either.

Might anyone have any solutions to the above they might share?

Ken Gordon
 
OK, I have done several things here: first, I installed a new (old) Intel CT NIC, then edited loader.conf, and rc.conf to activate the card. According to dmesg the card, em0, is active and the link is up. Even so, there is still no network connection.

pciconf -lv in part, returns this:

em0@pci0:5:0:0: class=0x020000 rev=0x00 hdr=0x00 vendor=0x8086 device=0x10d3 subvendor=0x8086 subdevice=0xa01f
vendor = 'Intel Corporation'
device = '82574L Gigabit Network Connection'
class = network
subclass = ethernet

none9@pci0:6:0:0: class=0x020000 rev=0x03 hdr=0x00 vendor=0x8086 device=0x15f3 subvendor=0x1043 subdevice=0x87d2
vendor = 'Intel Corporation'
device = 'Ethernet Controller I225-V'
class = network
subclass = ethernet

So, obviously I am still doing something wrong. Any ideas?

I CAN attach the full output of dmesg. but it is pretty long...

Ken Gordon
 
OK. I thought I might try Intel drivers, but the MAKE for their em-7.7.8 failed. Then after suggestions here, I abandoned that idea completely.

I will post both my loader.conf and my rc.conf here as soon as I can. The reason it takes so long for me is that I have to shut Windoze down completely, then fire up FreeBSD, copy the files to my Windoze desktop, then reboot into Windoze, then post those here.

Ken
 
OK. Here is my loader.conf:

security.bsd.allow_destructive_dtrace="0"
kern.geom.label.disk_ident.enable="0"
kern.geom.label.gptid.enable="0"
if_em_load="YES"
opensolaris_load="YES"
zfs_load="YES"
fusefs_load="YES"

And here is my rc.conf

hostname="Office"
ifconfif_em0="DHCP" <-----------ERROR HERE
ifconfig_em0_ipv6="inet6 accept_rtadv"
ifconfig_re0="DHCP"
ifconfig_re0_ipv6="inet6 accept_rtadv"
sshd_enable="YES"
moused_enable="YES"
ntpdate_enable="YES"
ntpd_enable="YES"
powerd_enable="YES"
# Set dumpdev to "AUTO" to enable crash dumps, "NO" to disable
dumpdev="NO"
zfs_enable="YES"
pf_enable="YES"
pf_rules="/etc/pf.conf"
pf_flags=""
pflog_enable="YES"
pflog_logfile="/var/log/pflog"
pflog_flags=""
dbus_enable="YES"
hald_enable="YES"
mysql_optfile="YOUR_CNF_FILE"
cupsd_enable="YES"
devfs_system_ruleset="system"
# SNMP STUFF
# snmpd_enable="YES"
# snmpd_flags="-a"
# snmpd_conffile="/usr/local/share/snmp/snmpd.conf /etc/snmpd.conf"
# snmptrapd_enable="YES"
# snmptrapd_flags="-a -p /var/run/snmptrapd.pid"
# SNMP MAKE VARIABLES
# NET_SNMP_SYS_CONTACT="zi@FreeBSD.org"
# NET_SNMP_SYS_LOCATION="USA"
# DEFAULT_SNMP_VERSION=3
# NET_SNMP_MIB_MODULES="host smux mibII/mta_sendmail ucd-snmp/diskio"
# NET_SNMP_LOGFILE=/var/log/snmpd.log
# NET_SNMP_PRESISTENTDIR=/var/net-snmp

kld_list="nvidia-modeset"
microcode_update_enable="YES"

And I can see the error that is probably causing my problem. I fat-fingered it. Blast it. OK. I'll fix that and reboot.

Ken
 
Top