Realtek RTL NIC is unreachable after update 175

Just for my own curiosity, can you enter these commands from here:
(your current setup will work a-ok!)

https://wiki.ipfire.org/hardware/networking#howto-identify-devices

This is what I see:

[root@ipfire ~] # lspci | grep -ie network -ie ethernet -ie wireless
01:00.0 Ethernet controller: Intel Corporation I211 Gigabit Network Connection (rev 03)
02:00.0 Ethernet controller: Intel Corporation I211 Gigabit Network Connection (rev 03)
03:00.0 Ethernet controller: Intel Corporation I211 Gigabit Network Connection (rev 03)
04:00.0 Ethernet controller: Intel Corporation I211 Gigabit Network Connection (rev 03)

[root@ipfire ~] # lspci -nn -v -s 01:00.0
01:00.0 Ethernet controller [0200]: Intel Corporation I211 Gigabit Network Connection [8086:1539] (rev 03)
	Subsystem: Intel Corporation I211 Gigabit Network Connection [8086:0000]
	Flags: bus master, fast devsel, latency 0, IRQ 24
	Memory at d0000000 (32-bit, non-prefetchable) [size=128K]
	I/O ports at 1000 [size=32]
	Memory at d0020000 (32-bit, non-prefetchable) [size=16K]
	Capabilities: [40] Power Management version 3
	Capabilities: [50] MSI: Enable- Count=1/1 Maskable+ 64bit+
	Capabilities: [70] MSI-X: Enable+ Count=5 Masked-
	Capabilities: [a0] Express Endpoint, MSI 00
	Capabilities: [100] Advanced Error Reporting
	Capabilities: [140] Device Serial Number 00-0d-b9-ff-ff-5a-b9-d8
	Capabilities: [1a0] Transaction Processing Hints
	Kernel driver in use: igb
	Kernel modules: igb

[root@ipfire ~] # 
1 Like

Jon,

Unfortunately I can’t connect with SSH to get you a full log but connecting a screen and keyboard I get this:

root@ipfire ~] # lspci | grep -ie network -ie ethernet -ie wireless
2:00.0   Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 15)

[root@ipfire ~] # lspci -nn -v -s 02:00.0
[root@ipfire ~] #.....
Adapter [10ec:8168]
!!!unknown header type 7f
i/o ports at 3000

hope this helps

My results for a Realtek rev 11 might be more informative:

It looks strange that your result from the same command is essentially blank. lspci ought to be able to report for the hardware, even if there is no relevant section in the driver module.

1 Like

Better still, hare are the results for a rev 15:

rx425:~ # lspci -nn -v -s 04:00.0
04:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 15)
Subsystem: Realtek Semiconductor Co., Ltd. RTL8111/8168 PCI Express Gigabit Ethernet controller [10ec:8168]
Flags: bus master, fast devsel, latency 0, IRQ 17
I/O ports at e000 [size=256]
Memory at fe904000 (64-bit, non-prefetchable) [size=4K]
Memory at fe900000 (64-bit, non-prefetchable) [size=16K]
Capabilities: [40] Power Management version 3
Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
Capabilities: [70] Express Endpoint, MSI 01
Capabilities: [b0] MSI-X: Enable+ Count=4 Masked-
Capabilities: [100] Advanced Error Reporting
Capabilities: [140] Virtual Channel
Capabilities: [160] Device Serial Number 01-00-00-00-68-4c-e0-00
Capabilities: [170] Latency Tolerance Reporting
Capabilities: [178] L1 PM Substates
Kernel driver in use: r8169
Kernel modules: r8169

Note that is running openSUSE Leap 15.5 kernel 5.14.21 plus lots of patches.

1 Like

Based on my searching this response to the lspci command is an indication that either the card in the pci slot or the pci subsystem on the motherboard has a fault and is incorrectly responding to the lspci command.

3 Likes

Agreed.

It is also possible that contacts in the PCIe slot are dirty. Merely blowing out dust, or failing that, a clean, using isopropyl alcohol can fix that.

Putting any known, working (expendable) PCIe video card in the slot would test whether or not there is a fault.

4 Likes

It was working flawlessly until the update to 175.

But I get it, it might be the PCIe slot. Blowing and cleaning with alcohol didn’t make a difference.

I installed another identical card into a different slot ( The full PCI) and it has similar issues, but after a few restarts the 2nd card works,

I upgraded to 177-testing, it made no difference.

I tried to switch between 1st and 2nd card using setup assigning NIC to Green and the “2nd card in the full slot” always needs a few restarts but then it works. The 1st card doesn’t.

I see someone else is experimenting with the same Rev 15

Your problem could be a BIOS issue:

  • Older BIOS require the PCI status to be reset, when cards are changed. By setting either Clear NVRAM to Y or PCI Reset to Y - then reverse those settings at next boot
  • PnP OS setting, which generally should be Yes for Linux - try toggling that
1 Like

Project Beema has a few issues to resolve, before it will be clear whether or not his RTL8111 card is working.

I unpacked CU 176 stable img.xz to a uSD card and booted it on my workstation having the RTL8111 rev 15. This post is coming via that IPFire.

Conclusion is that RTL8111 rev 15 fundamentally works with IPFire. One slight difference is that mine is on the mainboard whereas yours is on a card. My reading is that Realtek make different variants, depending on whether for mainboard, card or USB dongle.

It still looks like a mainboard problem at your end. You indicated that it is an older PC. Perhaps it is failing.

1 Like

I have a similar issue with the DHCP server of IPFire, I don’t know if it is related.

Because my firewall appliance gets so hot I turn it off at night, so I won’t die in a fire, j/k. :fire:

The next day I start my PC and then the hardware appliance, because the PC is faster it gets a link-local address. After I disable my NIC and enable it again it gets an IP assigned. My desktop OS is Windows 11.

Normally my Windows DHCP client and the IPFire DHCP server should handle out an IP automatically.

Here is my network identification:

[root@ipfire ~]# lspci | grep -ie network -ie ethernet -ie wireless
01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06)
02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 15)
[root@ipfire ~]# lspci -nn -v -s 01:00.0
01:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 06)
        Subsystem: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:0123]
        Flags: bus master, fast devsel, latency 0, IRQ 24
        I/O ports at e000 [size=256]
        Memory at fe900000 (64-bit, non-prefetchable) [size=4K]
        Memory at e0800000 (64-bit, prefetchable) [size=16K]
        Capabilities: [40] Power Management version 3
        Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
        Capabilities: [70] Express Endpoint, MSI 01
        Capabilities: [b0] MSI-X: Enable+ Count=4 Masked-
        Capabilities: [d0] Vital Product Data
        Capabilities: [100] Advanced Error Reporting
        Capabilities: [140] Virtual Channel
        Capabilities: [160] Device Serial Number e4-00-00-00-68-4c-e0-00
        Kernel driver in use: r8169
        Kernel modules: r8169

[root@ipfire ~]# lspci -nn -v -s 02:00.0
02:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 15)
        Subsystem: Biostar Microtech Int'l Corp RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [1565:2312]
        Flags: bus master, fast devsel, latency 0, IRQ 35
        I/O ports at d000 [size=256]
        Memory at fe804000 (64-bit, non-prefetchable) [size=4K]
        Memory at fe800000 (64-bit, non-prefetchable) [size=16K]
        Capabilities: [40] Power Management version 3
        Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
        Capabilities: [70] Express Endpoint, MSI 01
        Capabilities: [b0] MSI-X: Enable+ Count=4 Masked-
        Capabilities: [100] Advanced Error Reporting
        Capabilities: [140] Virtual Channel
        Capabilities: [160] Device Serial Number 01-00-00-00-68-4c-e0-00
        Capabilities: [170] Latency Tolerance Reporting
        Capabilities: [178] L1 PM Substates
        Kernel driver in use: r8169
        Kernel modules: r8169

[root@ipfire ~]#

As a general procedure, don’t start your PC until after the IPFire has finished booting. Then Windows 11 should accept an IP address that is offered by the IPFire.

You need to resolve the heating problem with your BIostar mainboard or risk it being damaged

I tested it again with the cable router, Windows only seems to look for a DHCP server for about a minute and then gives up. When it detects a removed network cable it looks again for a DHCP server.

I received a larger SFX-L PSU with a 120 mm fan today, this will hopefully show some improvement.