Realtek RTL NIC is unreachable after update 175

Getting Started with IPFire Updates Trouble
1

I just updated to core 175 and everything went well until I rebooted.

Now I have no networking. When I try to ping 192.168.1.1
IP is unreachable meaning GREEN in unreachable,
WUI is unreachable.

My setup is simple just RED and GREEN and using an older Intel PC with 8GB RAM and 2 NIC’s.

Looking at the both NIC’s they are both showing traffic with LED blinking.

I plugged in a monitor and rebooted a few times, no errors, everything shows OK.
DHCP OK . Green IP is 192.168.1.1 is OK,
RED IP renewed OK

I put the client PC on static IP 192.168.1.10 and still the GREEN IP is unreachable, WUI is unreachable. PC Ethernet shows as Unidentified network.

Did I miss any troubleshooting steps?

2

That upgrade on my simple RED & GREEN IPF had no problems.

It’s usually worth running “ifconfig”, from a terminal, as a first step in diagnosing network issues.

If green is not active, after boot completes, then a simple “ifconfig green0 up” might resolve the issue. Can you readily identify the MAC address of each NIC, then run Setup → Networking and confirm the settings for green0 and red0.

If you are running an intermediate Ethernet switch on your LAN, then repowering that can make a difference.

1 Like
3

Just for information.
Maybe it will be helpful.

BR

1 Like
4

The GREEN is active on the IPFIRE,
ifconfig shows the right mac address and IP address, just 0 packets.

I also ifconfig green0 down and then up , no change

I tried setup-networking- confirmed all is good,
restarted network,
the DHCP still :assigns 169.254…addresses not 192.168.

very unusual., I don’t want start from scratch and reinstall IPFIRE.

Last thing I will try is to switch NIC’s,
I wonder if the Realtek one has issues with the new kernel

5

I swapped the NIC’s and looks like I can reach GREEN.
RED is now not working

unbound: [3547:0] error: SERVFAIL <1.ipfire.pool.ntp.org.lan. AAAA IN>: exceeded the maximum numb er of sends

Intel is good
Realtek is the one not working.

7

I downgraded to core174 with same exact issues.

Looking at the release notes for core 173, I will have the same issue

Linux Kernel 6.1.11

Arne has updated the Linux kernel to the most recent stable series, 6.1.11, which has become the new long-term series. Aside from the usual improvements such major

this means I will be stuck at 172 for good :frowning:

8

Have you re-installed Core Update 172 and confirmed that the NIC is working again and not broken?

9

Thank you for checking back. Do you think it would just break right after the upgrade?

I will reinstall right now and will report back.

10

Yes, that can happen. The reboot phase can be more stressing for electronics so something near the end of its life can be pushed over the edge and fail. People on the forum have experienced that in the past.

Of course it can also be a driver problem in the kernel so the re-install test result will be interesting to see.

2 Likes
11

Another option would be to upgrade to CU176 Testing, which has a later kernel 6.1.30 and might have different modules for Realtek. However, that would need a working RED0, so you would need to swap interfaces again. You could still then reinstall, if needed.

Can you run “lspci” and ascertain what model of Realtek you have ?

12

I installed core 172 and unfortunately it didn’t change anything although the Green LED was on.
So I replaced the NIC with a brand new one which was still sealed and it made no difference. The LED is on but the Green interface still doesn’t respond.

I put the old NIC back and after setup - network assign and another reboot it started to respond. That’s good news.

So both NIC’s are identical, and are recognized in the Setup-network -assign and both of their LED’s are on when plugged in. They just won’t respond to request.

At least for now I have the old one working again.

13

Thanks for the advice the Realtek is a pretty common chip:

`
Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 15)
’

14

My onboard NIC, used as RED0, reports the same. However, there are multitude Realtek chips reporting the same, fairly generic, type. Mine loads the free software module rtl8169 and has worked without difficulty, through several CU upgrades.

Do you have a different PCIe slot on the mainboard to try ? Even the x16 slot for video cards would work.

There is an issue with rtl8169 module - see alternate driver rtl8168

1 Like
15

Thank you for the workaround, although it is dated March 2021,
I never had issues until I upgraded last week
I included lsmod results below:

I only have 1 PCIe,

I will try the x16 when I have some downtime in the summer.

# lsmod | grep r816

r8169                 102400  0
16
  • You also reverted back to a Core Update 172 install and the system still did not work.
  • Then you replaced the network card with a brand new one and that also didn’t work.
  • Then you put the old network card back in again and then it worked again.

If the issue was with Core Update 175 (kernel or other driver issue) then changing back to the previously working Core Update 172 would have resulted in a working system straight away.

Getting the system working again by plugging in and out the network cards a couple of times suggests more of a hardware problem of some sort to me.

3 Likes
17

I agree that it suggests a hardware problem.

The computer should have been disconnected from mains power between NIC changes ? OP said it was an older computer and the coin-cell might be weak.

3 Likes
18

A bit of my foot here, but have you checked if BIOS settings weren’t somehow changed for internal LANS and the BIOS battery still working? The Realteck NIC’s had a vulnerability problem few month’s ago (wondering where I reed it!)
G70P
Regards

1 Like
19

Thank you for all the responses, so I have tried to get more information in this issue:

So far core 172 is working great, even considering the issues when I downgraded.

I wanted to get to the core of the issue why did it fail with core175:

I have a few of these Realtek cards, they are identical just few months old. I used them briefly with PFsense/FreeBSD and debian.

Again these show up in IPFIRE as “Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 15)”

So I got another old desktop and put a 3rd Realtek NIC (never used with IPFIRE before. )

I tried to recreate my issues:

  • I installed core 172 and assigned
    RED: Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 15)

GREEN: built in Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 0)

The desktop had a very similar NIC built in - the only difference seems to be (rev0)

and the GREEN NIC worked great. this is the built in Rev0
the RED NIC got assigned without issues but it couldn’t get and IP again. this is the Rev15 , that I just installed and it works fine with Debian, PFsense.

so this can’t be caused by a hardware issue, or damage, just something with this particular (Rev15) is not working properly, I looked for system logs for RED and it wouldn’t show anything unusual.

I tried to reboot, without success and I tried 2 more reboots and after 3rd reboot RED interface finally got an IP assigned. :grinning:

Just like that, started to work properly.

Then I upgraded to core 175, this time I had zero issues, and both NIC’s are responsive. all works great.

So if you want to save yourself headaches, avoid this particular Realtek Rev15.

2 Likes
20

It could be difficult to ascertain what revision is in a boxed card. I have many RTL chips:

  • card having rev 06 running IPFire CU 176 fine (as GREEN0)
  • onboard rev 11 running openSUSE Leap 15.5 fine (that’s kernel 5.14)
  • on newer mainboards, not currently running but OK and unpredictable revision

I suggest that you retain your cards. Those could well work with a later kernel in IPFire.

The erratic behaviour that you experienced is similar to mine, in IPFIre, with the (unsupported) Friendlyarm Nanopi R1S H5. Re-running Setup → Network from console often resolved it, but is not a suitable workaround for long term use.

1 Like
21

I was curious to see if upgrading to core 176 would resolve anything.

My last update was getting both IPfire PC’s, somehow working with core 175

So once I upgraded from 175 to 176, the GREEN interface stopped working again.

Prety much the same story
ifconfig shows it has an IP address 192.168.1.1 , the LED light up green. but would not respond to PING. it wouldn’t assign DHCP address to clients.
-I tried multiple reboots, multiple “ifconfig down”, and “setup assign NIC”

this time none of the tricks were working for core 176 .
RED interface with an Intel NIC has zero issues, as usual :wink: (

I agree, @rodneyp , I will have to wait for another release.