Slackware64-14.2 gets confused when I plug in a second Ethernet card
 

I have installed Slackware64-14.2 on a computer with network card integrated
into the motherboard. After that /etc/udev/rules.d/70.persistent-net.rules
looked like this:

(I have grayed out the MAC address)

I have plugged in a second network card - a TP-LINK TG-3468. A couple of
searches show that it is Linux friendly. Then strange things start happening.

Snippet 1 from the output of dmesg:

Notice that it looks like there are two network cards (there are two indeed),
but their MAC address shows up the same.

Snippet 2 from the output of dmesg:

Here the booting process stops for good seconds (20-30 at least). Right after
that the next line in the log is:

and then the boot process continues.

A few lines below there's another network related message:

Snippet 3 from the output of dmesg:

After the boot process is completed and I log in, here is the output of
'ifconfig -a'

Notice that both eth0 and eth125 (I have no idea why was it named eth125) have
the same MAC address - the one that appeared in dmesg above twice for both
eth0 and eth1.

I am also attaching the relevant snippet from the output of lspci -vvv:

Note: The Device Serial Number for both items is grayed out again, but it's
the same.

When I boot another OS, both network cards are detected fine and work. I have
also used it to find the MAC address of the second network card. Let it be
yy:yy:yy:yy:yy:yy

I have tried to modify /etc/udev/rules.d/70.persistent-net.rules and enforce
it. After my change, the file looks like this:

But this did not change anything. After a reboot the problem persists.

The network rules are created by eudev, which in turn takes its cues from the kernel. In this case, it seems like the kernel is reporting the same NIC twice, which looks very much like an issue with the RealTek driver.

Which kernel are you running? Could you post the full output from dmesg?

Try booting from a live CD image, like System Rescue CD, and see if the issue persists.

While old, this may be of some use: https://www.linuxquestions.org/quest...debian-886789/

Your /etc/udev/rules.d/70.persistent-net.rules looks OK and it should work (enforce) but your current (kernel version ??? - run uname -a ) r8169 driver (which is known to be buggy) is creating two interfaces. This might work well with only the r8169 card but udevd gets confused when the second card is inserted and tries to allocate a name for it.
I'd suggest to delete the /etc/udev/rules.d/70.persistent-net.rules (backup it somewhere), reboot, check if r8169 is still eth0 and what the TG-3468 got named to, and follow the referenced link and the two utilities from within the last post and rename the interfaces manually at the very beginning of the /etc/rc.d/rc.inet1 script:
https://www.linuxquestions.org/quest...9/#post5776770

Regarding the renaming of eth125 (which, without having the complete dmesg output, I guess it's the TG-3468 card - as it looks to remain eth125 from your ifconfig output) into the existing eth0 (already assigned to the r8169) by udedv:
this might give you some explanations:
https://github.com/systemd/systemd/issues/2657

The generic 4.4.14 kernel. It's a fresh Slackware64-14.2 install, I did not apply any updates from patches/ yet. I know I must, but I thought maybe I can settle this NIC issue first, so I won't go back. If none of the suggestions in this thread will work, I will update and try them again, to see if the newer kernel fixes it.

It is too big to fit into a forum post. I have cut the header and start where I've noticed the network related message. MAC address at line 3 and 7 is grayed, but it's the same for both eth0 and eth1. But I have also posted the full dmesg output here https://dpaste.de/yPDt

I have just downloaded SystemRescueCd-x86-5.1.2, made a bootable flash drive and booted from it. The problem persists. I'm getting two different network interfaces (albeit named slightly differently), but in the output of ifconfig -a both have the same MAC address. It matches with the MAC address from dmesg, so it's the same NIC - the integrated one.

4.4.14 but I will update to 4.4.88 if I don't manage to get this networking issue fixed first

I deleted /etc/udev/rules.d/70.persistent-net.rules, rebooted, network cards got named eth0 and eth1 without that big delay, but:

1. ifconfig -a shows that both eth0 and eth1 still have the same MAC address - the integrated NIC
2. after one more reboot the whole problem is back: I get that giant delay again and interfaces named eth0 and eth126 (not eth125 like last time)

Before I get to read the manpages for ifrename and nameif, and try playing with these tools, I have the following questions:

1. As I understand the kernel / udev voodoo happens before rc.inet1, how will my attempt to rename the interfaces get rid of the ugly delay at boot? I certainly don't want to wait for so long during each system boot. Of course I could stick a 'rm /etc/udev/rules.d/70.persistent-net.rules' into the shutdown script so the system always starts with that file missing, but then I'll get different names and will have to look for the correct interface name to rename.

2. I am confused that the MAC address of the second NIC (the TP-LINK one, which I know), doesn't appear anywhere in dmesg. Will attempts to map an interface name by that MAC address using the ifrename/nameif tools work if they didn't work via /etc/udev/rules.d/70.persistent-net.rules?

Considering the kernel is what provides the module for the network cards, the first thing I would do is update to the latest kernel (at least 4.4.88 provided by Slackware, but you could also go to the latest from kernel.org, which is 4.4.100 -- you can either compile it yourself or use 55020's "dusk" kernel packages) to see if the issue has been fixed. You could also try the driver directly from Realtek. I know others have had success with that.

I'm wondering how did you get the first r8169 adapter working out-of-the-box in the first place, this fellow Slacker had issues with it:
https://www.linuxquestions.org/quest...on-4175616651/

Sorry, I was not aware that the "Linux Friendly" TP-LINK TG-3468 is driven by the same Realtek chip - r8169 and the afferent buggy driver. This explains everything now, especially why and how (same MAC) udev is getting confused. It's a pure driver issue.

Try this workaround - basically you need to tell udev with the help of KERNELS== parameter which card is which in /etc/udev/rules.d/70.persistent-net.rules, do respect the effective MAC addresses corresponding to the cards (pci addresses) listed with lspci:
https://ubuntuforums.org/showthread....0#post12093090


On your questions:
1. udev is launched before /etc/rc.d/rc.inet1, you'll find it in /etc/rc.d/rc.S and then again (checked) in /etc/rc.d/rc.M just before /etc/rc.d/rc.inet1
The header of /etc/rc.d/rc.inet1 is an easy and safe (dirty too) place to fine tune/modify your adapters before configuring their addresses.

2. Forget those utilities, you have a driver issue that should be fixed in the kernel / udev zone


Note to myself: it looks like the r8169 driver is haunting me these days, every time I try to help on a system/networking issue the r8169 thing is popping up and telling me to avoid such "Linux Friendly" cards :)

I did nothing else than doing a full install, the integrated NIC just worked.

Adding this additional data (copypasted from the suggested link, so the MAC addresses are from that example):

only fixes the delay at boot. I'm still getting an eth0 interface and an eth100something interface.

I went one step further and edited /etc/udev/rules.d/70.persistent-net.rules one more time, removing the hardcoded MAC addresses, so it rather looked like this:

One more reboot and this time I get the correct interface names: eth0, eth1.

But the main problem persists: in output of dmesg kernel still reports the same MAC address (the one of the integrated NIC) for both eth0 and eth1.

It looks like it's indeed a kernel/driver issue rather than an udev one, that's why I will attempt a system update later today, which will also upgrade the kernel from 4.4.14 to 4.4.88, and then will report the results here.

Just upgraded the system, problem persists. Kernel 4.4.88 behaves exactly like 4.4.14.

For now I am hesitating to try 4.4.100 as well, because it's unofficial and I'm trying to stay with stock Slackware kernel.

I have also tried to download the r8168 driver from Realtek, as suggested above, but build fails:

Unpack and get into that directory:

This is on kernel 4.4.88 already.

Hello,

There's a slackbuild for this realtek driver which builds fine on 14.2.

--
SeB

For some reason, it never crossed my mind to look on SBo, since in my mind queue getting sbopkg was a few steps away.

I have used the buildscript from SBo and after another reboot everything magically works. So this was indeed a kernel driver issue. Thanks to everyone who helped. Marking the thread as solved.

Happy to hear that you got it finally working! Good to have all this effort documented on this thread.

I was reluctant to advise you to use r8168 driver, because I remember reading somewhere (some very old threads - years ago) that the r8168 driver, while originally provided by Realtek, is not maintained anymore and was incorporated in the new r8169 that is actively maintained by the kernel folks. I'm wondering if you have full Gigabit and Auto-negotiation capabilities with the old r8168 driver you are using now - you can check with:
In my instructions I've specifically used the word effective MAC addresses just fearing that not all drivers would support MAC cloning. I should have used the word real instead, maybe transcribing the instructions from that Ubunutu thread myself would have been a better option, I was just trying to be efficient by only pointing you to that. Worth trying again with the r8169 driver and real MAC addresses.


Should you have a little time, you could provide some feedback to the r8169 driver developers, they surely need it, in order to get this driver fixed in the future kernel releases. It'll help you, the Linux community and nobody will call the otherwise perfect Slackware distro confused again ;)

ethtool reports that Auto-negociation is enabled and Speed is 1000Mbps for both cards.

To avoid any confusion: I have said "I copypasted from the suggested link, so the MAC addresses are from that example" in context of my forum post, to cloak the real MAC addresses of my NICs (Big Brother paranoia, though I won't be surprised if that info slipped somewhere in the huge logs that I've posted). On the real computer, I have used the real MAC addresses of both cards, I did not try to enforce a MAC address change anywhere.

Frankly, I have no idea how would I do that, where would I go and what exactly would I say. I only know that kernel devs use mailing lists (I have always had a aversion for email mixed with a phobia for mailing lists) for communication, I randomly read that they are sometimes very harsh on others (usually not personally, but during debates on technical details). I am just a random Internet guy who doesn't even speak English natively (luckily, it was enough to ask for help in this forum and understand the suggestions), so if everything I need worked perfectly right after the Slackware install (I've had such experiences with older versions of Slackware and older hardware from pre-UEFI era), I would just keep staying low-profile under my virtual rock and never come out to cry for help :)

Now that you said that, perhaps I wasn't very careful with my choice of wording (see above about my English skill level). Let me take those words back then and say that I was the confused one :)

Realtek seems to be updating their driver. The last update is Sep 2017. Looking at the git log for the SlackBuild, it shows that since it was added to the repo back in Jan 2016, there's been 5 updates.

But I do agree it would be nice to get this information to the kernel developers. It'd be interesting to see if it is fixed in kernels newer than the 4.4 series. They're up to the 4.14 and it's very possible that it was fixed in one of the subsequent kernels and just never backported.

@FlinchX
Thanks for the clarifications, it looks like the r8169 driver is not really functional in this 2 cards scenario and the r8168 should be used instead ATM. Your English is good, don't worry about it, I'm also not a native speaker. Regarding your privacy concerns, you're not the only one and paranoia is just heightened awareness, remember that ;)

I was suggesting to get in touch with the developers yourself just because they might ask some HW details that I couldn't provide as I don't own any r816x NICs. Anyways, I just sent an E-mail to the two developers (originators) found in the header of the source file and asked them politely to take a look at this thread and the other one related that I referenced above.
https://github.com/torvalds/linux/bl...ealtek/r8169.c

@bassmadrigal
EDIT>
The r8168 driver you referred to looks to be maintained by a single contributor that takes it from Realtek. I was under the impression that Realtek stopped the development on it and that the r8169 took it's place:
https://git.slackbuilds.org/slackbui...b2110e283e9d4a
https://github.com/mtorromeo/r8168/

Related to the r8169 kernel supported driver, it is actively maintained but it's a little difficult to go through all the changes and try to relate them with the issues observed.
https://github.com/torvalds/linux/co...ealtek/r8169.c
I'm concerned about this driver because it looks like the Realtek chips that require this driver are getting used more often in Motherboards / NICs.

It looks like mtorromeo is just mirroring the source from Realtek onto github. Based on one of his other repos, he might be an Arch user and was just looking for a better way to host the source for an AUR package.

It'd certainly be interesting if that issue is still happening with a newer kernel.

Posting here for further reference. Earlier today I have noticed the kernel update in Slackware64-14.2. I got myself a local copy of buildscript and source code for r8168 from SBo. The kernel update to version 4.4.111 killed my network again, so the problem persists for this kernel version too. I had to manually rebuild the package for r8168 against the new kernel, install it, then I got my network interfaces back.

@MadMaverick9 full disclosure hurts egos :)