Ethernet Puzzle

Home » CentOS » Ethernet Puzzle
CentOS 11 Comments

So I just finished doing a fresh install of CentOS 6.3. The machine has three ethernet ports in it: one on the motherboard (VIA
Rhine), and two add-on cards, an Intel Pro100 and an old SMC1255TX. When CentOS comes up, this is what I see in the dmesg output:

# dmesg | grep eth
e100 0000:00:08.0: eth0: addr 0xf6043000, irq 16, MAC addr
00:02:b3:be:02:87
eth1: ADMtek Comet rev 17 at MMIO 0xf6040000, 00:4c:69:6e:75:79, IRQ 17.
udev: renamed network interface eth0 to rename2
udev: renamed network interface eth1 to eth3
udev: renamed network interface rename2 to eth1
eth0: VIA Rhine II at 0xf6042000, 00:16:17:17:22:8e, IRQ 23.
eth0: MII PHY found at address 1, status 0x786d advertising 05e1
Link 45e1.
eth0: link up, 100Mbps, full-duplex, lpa 0x45E1
eth0: no IPv6 routers present

So, according to the musical playing going on there, the result is:

eth0: VIA Rhine
eth1: IntelPro 100 (originally comes up as eth0 but gets renamed eth1)
eth3: SMC1255TX (originally comes up as eth1 but gets renamed eth3)

Here’s my issue:

In udev rules (/etc/udev/rules.d/70-persistent-net.rules I see:

# PCI device 0x1113:0x1216 (tulip)
SUBSYSTEM==”net”, ACTION==”add”, DRIVERS==”?*”, ATTR{address}==”00:4c:68:6e:ff:ff”, ATTR{type}==”1″,
KERNEL==”eth*”, NAME=”eth2″

# PCI device 0x8086:0x1229 (e100)
SUBSYSTEM==”net”, ACTION==”add”, DRIVERS==”?*”, ATTR{address}==”00:02:b3:be:02:87″, ATTR{type}==”1″,
KERNEL==”eth*”, NAME=”eth1″

# PCI device 0x1106:0x3065 (via-rhine)
SUBSYSTEM==”net”, ACTION==”add”, DRIVERS==”?*”, ATTR{address}==”00:16:17:17:22:8e”, ATTR{type}==”1″,
KERNEL==”eth*”, NAME=”eth0″

# PCI device 0x1113:0x1216 (tulip)
SUBSYSTEM==”net”, ACTION==”add”, DRIVERS==”?*”, ATTR{address}==”00:4c:69:6e:75:79″, ATTR{type}==”1″,
KERNEL==”eth*”, NAME=”eth3″

Question is, where did the first tulip interface come from? That’s not any of the interfaces on the machine, it doesn’t match the MAC
address of any of the interfaces, so where’d it come from?

Furthermore, when I look in
/etc/sysconfig/network-scripts/ifcfg-eth2, the HWADDR there is the same as the first interface listed above. But again, it’s not in dmesg’s output. As far as I can tell, it’s a ghost interface …

What gives, and how can I get rid of it so that the proper interface gets the eth2 spot?

A

11 thoughts on - Ethernet Puzzle

  • By the way, I know that the tulip drives is what is driving the SMC1255TX
    … in case anyone was wondering if that’s what I’m asking. It’s not. It’s the hardware MAC address that’s puzzling to me as it doesn’t exist on this machine anywhere. At least not that I can tell.

  • Yeah, rpmforge or repoforge. But, I’m looking for what exactly? It only lists a single ethernet port (the built-in one).

    lspci lists the other two, and all of those MAC addresses are correct. The one that doesn’t match ONLY appears in the udev rules file.

  • That’s what you’re looking for. Now you know that the mysterious device isn’t something that you didn’t know aobout on the motherboard.

  • But it is. The MAC address on the motherboard port is NOT the same as the mystery device. And it DOES match one of the entries in udev’s rules, and it’s operational right now as eth0 (as it should be.) However, the mystery MAC address that’s listed in udev’s rules matches nothing in either lshw or lspci.

    Remember, udev’s rules lists FOUR devices. There are only THREE.

  • What does the BIOS say about ethernet devices?

    Does the motherboard have a management interface card with its own ethernet port, perhaps potential but not actually installed?

    Is there a fiber-optics connector on the system which is coming up as an ethernet port?

    Is one of the cards old enough to still have a separate BNC connector?

  • An IPMI may have its own MAC, but share a physical port with the main NIC. If you are using this as a firewall, make sure to not have an IPMI port facing the internet.

    You may have a MAC address in one of your ifcfg-eth* files that does not
    _exactly_ match the hardware. Sometimes, it can be case-sensitive. pushd /etc/sysconfig/network-scripts/
    mkdir BACKUP
    mv ifcfg-eth* ./BACKUP/
    I would take out all the add-on cards and see if this extra MAC stays around. Put the other cards in one-by-one till found.

  • BIOS lists one device.

    Motherboard does not have an interface card.

    No fiber optic.

    No BNC connector.

    I commented out the “ghost” MAC address from udev’s rules file and rebooted. It has not reappeared. However, the problem I have is that the ethernet ports don’t stick in the same order. They came up in a completely different order. I now have eth0, 1, and 4. What was eth0 prior to the reboot is now … uh … ‘rename4’ according to the udev messages:

    udev: renamed network interface eth0 to rename2 (this is the Intel Pro 100
    add-in card [e100 module])
    udev: renamed network interface eth1 to eth0 (this is the SMC1255TX add-in card [tulip module])
    udev: renamed network interface rename2 to eth1
    udev: renamed network interface eth2 to rename4 (this is the motherboard ethernet port [VIA Rhine module])

    What gives?? How can I tell it to either stop mucking with them, or to do it in the order I want it to:
    on-board: eth0
    Intel: eth1
    SMC: eth2

  • I decided to completely delete everything out of udev’s rules file and restart the system. This brought up the devices in whatever discovered order. Then I modified the rules file to set them in the correct order
    (simply by changing the NAME= key) and rebooted again.

    Now they’re all coming up in the order in which I set them. The mystery MAC hasn’t reappeared either. It seems to only be present immediately after the install. I’ve now rebooted three times to make sure the definitions stick. So far so good.

    While this has solved the problem, it still doesn’t explain the mystery MAC. but, I’m willing to concede that we will never find out where it came from.

LEAVE A COMMENT