Ethernet device's MAC address changes (causing its device number to increase by one each time)

$ cat /etc/udev/rules.d/70-persistent-net.rules
# This file maintains persistent names for network interfaces.
# See udev(7) for syntax.
#
# Entries are automatically added by the 75-persistent-net-generator.rules
# file; however you are also free to add your own entries.

# PCI device 0x10de:0x054c (forcedeth)
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:00:6c:cf:97:0d", NAME="eth0"

# PCI device 0x10de:0x054c (forcedeth)
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:00:6c:ed:c4:70", NAME="eth1"

# PCI device 0x10de:0x054c (forcedeth)
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:00:6c:a9:6b:29", NAME="eth2"

# PCI device 0x10de:0x054c (forcedeth)
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:00:6c:23:7e:8b", NAME="eth3"

# PCI device 0x10de:0x054c (forcedeth)
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:00:6c:1b:91:55", NAME="eth4"

# PCI device 0x10de:0x054c (forcedeth)
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:00:6c:5f:d5:8e", NAME="eth5"

# PCI device 0x10de:0x054c (forcedeth)
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:00:6c:ee:7e:7b", NAME="eth6"

# PCI device 0x10de:0x054c (forcedeth)
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:00:6c:d6:3a:53", NAME="eth7"

# PCI device 0x10de:0x054c (forcedeth)
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:00:6c:40:00:0c", NAME="eth8"

Sorry, here is the Debian forum thread:
http://forums.debian.net/viewtopic.php?p=107155

This is happening to me on Gutsy RC installation.

Let me know if any information is needed.

Yes, this is happening to me too on Gutsy and it's very annoying.

I am having a similar problem with Gutsy on my Acer Aspire 3023 WLMi: Wired ethernet alternates between eth0 and eth2 at boot, while WiFi is always eth1.

lspci -vv:
06:07.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet (rev 10)
        Subsystem: Acer Incorporated [ALI] Aspire 5024WLMi
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 64 (8000ns min, 16000ns max), Cache Line Size: 32 bytes
        Interrupt: pin A routed to IRQ 22
        Region 0: I/O ports at a000 [size=256]
        Region 1: Memory at c0209400 (32-bit, non-prefetchable) [size=256]
        [virtual] Expansion ROM at 64000000 [disabled] [size=128K]
        Capabilities: <access denied>

dmesg:
[ 7.224000] r8169 Gigabit Ethernet driver 2.2LK loaded
[ 7.224000] ACPI: PCI Interrupt 0000:06:07.0[A] -> GSI 23 (level, low) -> IRQ 22
[ 7.224000] eth0: RTL8169sb/8110sb at 0xf8846400, 00:0a:e4:e0:b1:0a, XID 10000000 IRQ 22

It turns out that I had set the MAC address in the WinXp driver software (different to the HW address) for the RTL8169 (I dual boot), which was then carried over to Ubuntu after a reboot - I guess Gutsy saw a new MAC address and assigned it to eth2. Or something... Why it alternated, I'm not sure. Possibly an Ubuntu-Ubuntu reboot would reset the MAC address to the HW MAC address, which would go back to eth0, and a WinXP - Ubuntu reboot would leave the software MAC address in place and result in eth2. Alternatively, powering down fully between OSes might reset the HW address.

/etc/udev/rules.d/70-persistent-net.rules

# PCI device 0x10ec:0x8169 (r8169)
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="xx:xx:xx:xx:xx:0b", NAME="eth0" ##<= MAC set in WinXP driver software

# PCI device 0x14e4:0x4318 (bcm43xx)
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="xx:xx:xx:xx:xx:5f", NAME="eth1" ##<= WiFi

# PCI device 0x10ec:0x8169 (r8169)
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="xx:xx:xx:xx:xx:0a", NAME="eth2"##<= hardware MAC address

Well, I'm also dual booting but I dont have anything like that specified under Win XP. And here it doesn't alternate, it keeps on increasing - currently I'm at eth34 :(
It is very annoying as I have to reenter the IP addresses every time and restart the networking interface.

what i did to solve the problem is the following. This has been found on the debian link in the second post, now my Ethernet is always eth0

1. edit /etc/udev/rules.d/70-persistent-net.rules

2. remove all the existing entries and add a new one, something like

SUBSYSTEM=="net", DRIVERS=="forcedeth", NAME="eth0"

Thanks 3zero2, I have made that change now, and i works fine. However, I think this still should be fixed. Also, I'm assuming that this workaround may cause problems if you have multiple ethernet cards.

I don't really know what repercussions in the system the fix I posted above might have. Unfortunately this bug is still set to new, don't know if the devs care about fixing it or if it is their responsibility. Maybe the bug is coming from a piece of code Ubuntu didn't write itself.

I know it also affects Debian due to this post in their forums http://forums.debian.net/viewtopic.php?p=107155

I'm not aware of any bugs in their tracker for this.

I'm seeing this too, on gutsy with a prism54 card and 2.6.23.8 or 2.6.24-rc3 kernel. (Ubuntu's 2.6.22 kernel doesn't boot on this machine.)
The only solution I found was to rm /etc/udev/75-persistent-net-generator.rules then fix 70-persistent-net.rules by hand to force it to eth1 or eth0.

Could this be related to the issue in bug 31502, where a wireless network card reports the wrong MAC address until after the firmware is loaded? I found lots of similar open bug reports in launchpad, all for wireless cards but each one a different chipset, but they all probably have loadable firmware.

I have a similar problem, but it happens on my wired network card too. When I boot my machine it works correctly. But then when I suspend/resume, the card gets a different MAC address. If I suspend/resume again, it gets back its correct MAC address. It continues to alternate between its correct MAC and a new one.

For example, in 6 resume/suspend cycles I got this result:

eth0 00:1B:24:0B:D1:E5
eth3 00:00:6C:BE:14:42
eth0 00:1B:24:0B:D1:E5
eth4 00:00:6C:1C:5E:CC
eth0 00:1B:24:0B:D1:E5
eth5 00:00:6C:7C:75:DE
eth0 00:1B:24:0B:D1:E5

This is on Gutsy with a custom linux 2.6.22.15 kernel. I'm also using the forcedeth driver, as some others above.

00:14.0 Bridge: nVidia Corporation MCP51 Ethernet Controller (rev a3)

I understand how to keep the ethX from changing, but what I really care about is the MAC address.

I don't think this will be fixed. If the MAC address is invalid, what is the driver to do? Other things can break if the kernel driver accepts the invalid data.

I have blogged about my experience and hack for it at http://davehall.com.au/blog/dave/2008/02/10/flakey-bios-gigabyte-ga-m68sm-s2l-makes-mac-address-change-reboot

I think that this really should be marked as a "kernel bug", as it is the kernel driver doing this, not udev. If only launchpad allowed you to file hardware bugs and they were sent to the appropriate vendor ...

I don't have much knowledge of this stuff, but Windows XP is able to detect the MAC address correctly (and it is the same every time) - so probably it's not a hardware fault?

But yes, it can be a kernel bug as you said. Can someone confirm if this should be reassigned to the kernel?

The kernel need not pic a *RANDOM* MAC address, it could use one that's at least predictable

NICs have correct MAC address stored at production time. Therefore some applications like macchanger (Linux) and some MoBo' BIOSes enable the user to change without any correctness check the MAC address.

To create a workaround to this, in the Linux kernel an attendibility check is performed in drivers/net/forcedeth.c, where a bug seems to be present.
If the LSB red is 1, the address is considered as a multicast type (read IANA specs) and evaluated as wrong.
In this case the code calls a random MAC address generator routine and the result is stored in the NIC.

The bug consists in the fact the MAC address is red with inverted byte order so every last digit higher then 7h will trigger the multicast type case during attendibility check.

Regards

I don't know if this is of any interest. I upgraded from ubuntu gutsy gibbon to hardy heron and this problem occurred. Booting with the previous kernel (2.6.22) and forcedeth driver 0.60 everything works. In 0.61, the MAC-address is in fact read backwards. This is the upgraded entry in the 70-persistent-net.rules;

# Converted from /etc/iftab on upgrade
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:13:8f:e9:da:e5", ATTRS{type}=="1", NAME="eth0"

I solved it by replacing it with;
# PCI device 0x10de:0x03ef (forcedeth)
SUBSYSTEM=="net", DRIVERS=="?*", ID=="0000:00:07.0", NAME="eth0"

and to get the correct MAC-address instead of the random one; /etc/network/interfaces
iface eth0 inet dhcp
        hwaddress ether 00:13:8f:e9:da:e5

Output from lspci;
00:07.0 Bridge: nVidia Corporation MCP61 Ethernet (rev a2)
        Subsystem: ASRock Incorporation 939NF6G-VSTA Board
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 0 (250ns min, 5000ns max)
        Interrupt: pin A routed to IRQ 21
        Region 0: Memory at dfffd000 (32-bit, non-prefetchable) [size=4K]
        Region 1: I/O ports at e480 [size=8]
        Capabilities: [44] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
                Status: D0 PME-Enable+ DSel=0 DScale=0 PME-
        Capabilities: [50] Message Signalled Interrupts: Mask+ 64bit+ Queue=0/3 Enable-
                Address: 0000000000000000 Data: 0000
                Masking: 00000000 Pending: 00000000
        Capabilities: [6c] HyperTransport: MSI Mapping

Scott James Remnant is correct: "The kernel need not pick a *RANDOM* MAC address, it could use one that's at least predictable"

This is an old problem that has bee solved. The Network Working Group documented the issue in 1998 and provided the correct solution: reverse the bit order of the LAN adapter to restore it to canonical form. See RFC 2469, http://tools.ietf.org/html/rfc2469.

If the kernel reads an apparently invalid MAC address, it should first try reversing the bit-order. If the reversed-bit-order is a canonically valid address, use the so-reversed MAC, per RFC 2469.

There is the remote possibility that reversing the bit order would not yield a canonically correct address. Consequently, if both the reported address and the reverse-bit-order address are *both* invalid, replace the Organizationally Unique Identifier of original MAC with a predetermined, specified OUI or Individual Address Block (IAB). (See http://standards.ieee.org/regauth/faqs.html). Ideally, the IEEE would assign a specific OUI or IAB for use by the Internet community in such cases. (It's not all that expensive and requests are processed within 7 days.) Such an approach would reuse the device-specific numbering already assigned by the vendor to the interface, and would likely result in fewer duplicates on the same LAN (although it would still be statistically possible).

Here's a summary of the logic I propose:

read address reported by hardware
is address valid?
     If yes, set MAC equal to address as reported.
     If no, set MAC (1) = reverse bit order of address reported
             is MAC (1) valid?
             if Yes, set MAC = MAC (1)
             if No, replace OUI of MAC with specific, predetermined OUI, and set MAC to the new value.
exit

Happy Trails,

Loye Young
Isaac & Young Computer Company
Laredo, Texas
http://www.iycc.net

The Ubuntu Kernel Team is planning to move to the 2.6.27 kernel for the upcoming Intrepid Ibex 8.10 release. As a result, the kernel team would appreciate it if you could please test this newer 2.6.27 Ubuntu kernel. There are one of two ways you should be able to test:

1) If you are comfortable installing packages on your own, the linux-image-2.6.27-* package is currently available for you to install and test.

--or--

2) The upcoming Alpha5 for Intrepid Ibex 8.10 will contain this newer 2.6.27 Ubuntu kernel. Alpha5 is set to be released Thursday Sept 4. Please watch http://www.ubuntu.com/testing for Alpha5 to be announced. You should then be able to test via a LiveCD.

Please let us know immediately if this newer 2.6.27 kernel resolves the bug reported here or if the issue remains. More importantly, please open a new bug report for each new bug/regression introduced by the 2.6.27 kernel and tag the bug report with 'linux-2.6.27'. Also, please specifically note if the issue does or does not appear in the 2.6.26 kernel. Thanks again, we really appreicate your help and feedback.

This is a bug in the Feisty kernel, and last time I checked the problem was still there. The real fix is to fix the forcedeth driver in Feisty, as based on what I have seen online this is an ubuntu only bug. If you aren't going to fix Feisty then I suggest you close the bug as WONTFIX and put a comment on it that it works with Hardy - I won't be upgrading production boxes (other than my laptop) to Intrepid anytime soon.

Dave: I did not have this problem with Feisty nor Gutsy, but I had it with Hardy (I fixed it using 3zero2's solution) so I think that what you are saying is incorrect.

I've had this problem in Gutsy and Hardy both, so a WONTFIX saying works with Hardy won't be right.

Leann: Are there 2.6.27 debs to install on Hardy? I wont be able to move to Intrepid yet, as this is my only laptop. I will be willing to give it a shot if there were 2.6.27 was available for Hardy, if they are safe enough and won't eat up my data.

Thanks!

The status of "won't fix" relates to the udev package, not to the issue as a whole. As mentioned above, the problem is not the udev package; it's the kernel driver that receives the MAC address from the network interface. Consequently, "won't fix" is the correct status for the udev package.

With respect to testing with the linux-image-2.6.27-* package, we have tested by installing the package with Hardy. Unfortunately, however, that kernel breaks the video driver and the framebuffer in a manner that makes the machine unusable, so we are unable to verify whether the linux-image-2.6.27-* kernel package fixes this bug.

Happy Trails,

Loye Young
Isaac & Young Computer Company
Laredo, Texas
http://www.iycc.net

IMHO, this should be marked as HIGH priority.

This bug breaks the networking for many machines, and few lay persons (or even geeks) would be able to figure out what happened. It's a deal-stopper for us OEMs, and many regular people, too.

What we're having to do at IYCC is rewrite several packages to work around the problem. This one problem is soaking up more developer time than all others combined.

Happy Trails,

Loye Young
Isaac & Young Computer Company
Laredo, Texas
http://www.iycc.net

I think that as long as the udev file for ethernet devices (70-persistent-net.rules) has right mac addresses it's not a kernel issue, but udev fault. What's more, if I remove all the references to any device and restart, udev regenerates this info in the right way. Restarting several times produces no change, so the configuration is stable, and even solves bug 148116 (at least my concerns).

It's my fault to not have investigated before, but I'm not udev expert to have guessed udev behaviour maybe not wise enough to determine "invalid" or duplicate definitions (maybe already customizable, but in a wrong logic?). Here's part of my previous udev file, with one built-in ethernet and a USB ethernet device:

# USB device 0x0b95:0x1720 (asix)
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:50:5b:00:b6:67", ATTR{type}=="1", NAME="eth2"

# USB device 0x0b95:0x1720 (asix)
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:50:5b:00:b6:67", ATTR{type}=="1", NAME="eth3"

# USB device 0x0b95:0x1720 (asix)
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:50:5b:00:b6:67", ATTR{type}=="1", NAME="eth4"

# USB device 0x0b95:0x1720 (asix)
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:50:5b:00:b6:67", ATTR{type}=="1", NAME="eth5"

# USB device 0x0b95:0x1720 (asix)
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:50:5b:00:b6:67", ATTR{type}=="1", NAME="eth6"

# USB device 0x0b95:0x1720 (asix)
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:50:5b:00:b6:67", ATTR{type}=="1", NAME="eth7"

And my built-in ethernet was being named eth8, until I deleted all entries and tested automatic configuration from scratch, where it becomes eth0 and this USB interface, eth1 (the right values for both).

So, taking the subject for this issue, I don't know why udev, with the same mac address (a valid mac address), was adding a new entry, increasing the value and breaking my scripts.

On Sun, 2008-09-14 at 10:18 +0000, Oscar Manuel Gómez Senovilla wrote:

> I think that as long as the udev file for ethernet devices (70
> -persistent-net.rules) has right mac addresses it's not a kernel issue,
> but udev fault.
>
You appear to have a completely different problem to the original
reporter. This bug is *ONLY* about network drives that generate a
random MAC address on each boot.

If the MAC address lines in your rules file are the same, please open a
new bug.

Scott
--
Scott James Remnant
<email address hidden>

Problem remains with latest intrepid:
Linux antibes 2.6.27-7-generic #1 SMP Tue Oct 14 18:38:59 UTC 2008 x86_64 GNU/Linux

00:0a.0 Bridge: nVidia Corporation CK804 Ethernet Controller (rev a2)
 Subsystem: Giga-byte Technology Device e000
 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
 Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
 Latency: 0 (250ns min, 5000ns max)
 Interrupt: pin A routed to IRQ 23
 Region 0: Memory at ec003000 (32-bit, non-prefetchable) [size=4K]
 Region 1: I/O ports at e800 [size=8]
 Capabilities: <access denied>
 Kernel driver in use: forcedeth
 Kernel modules: forcedeth

I never had this problem until I installed 8.10 Intrepid I386. Previous OS was Ubuntu 7.10 Gutsy X86_64 and from day one the Ethernet and Wireless worked. I didn't do an upgrade. I had a spare hard drive lying around so I figured that I would try the new Ubuntu before I fully commit to it. **I haven't installed the drivers for the wireless card yet.**

My network controllers are as told from lspci:

Wireless:
Broadcom Corporation BCM4306 802.11b/g Wireless LAN Controller (rev 03)

Wired **the one I'm having problems with**:
 nVidia Corporation MCP61 Ethernet (rev a2)

Wired was always eth0 and wireless was eth1 on my Gutsy install. I still have the Gutsy install on the other hard drive so if you want me to get information from it to help solve this just let me know. I'm still new to the Linux OS (almost a year), so if you tell me to get certain info from my 7.10 install be exact and list the command.

Jay

Per a decision made by the Ubuntu Kernel Team, bugs will longer be assigned to the ubuntu-kernel-team in Launchpad as part of the bug triage process. The ubuntu-kernel-team is being unassigned from this bug report. Refer to https://wiki.ubuntu.com/KernelTeamBugPolicies for more information. Thanks.

There appears to be absolutely no forcedeth development going on, or concern about this bug. As a horrible work-around, which lets NetworkManager consistently recognise the device as being the same (and may or may not fix suspend-resume) I wrote a dkms based patch for forcedeth which is in my ppa. It forces incorrect MAC addresses to be a fixed MAC, instead of a different random one each time. I just picked a random one, but this could be configured to match your card, or network requirements.

deb http://ppa.launchpad.net/waster/ppa/ubuntu jaunty main

>I just picked a
>random one, but this could be configured to match your card, or network
>requirements.

Thanks for running with this Jack.

IMHO, what you call a "horrible work-around" is on the right track to the
correct solution. Is there a way to have it remember from the first time the
system recognizes a valid MAC address? Maybe then a wag-and-a-poke script
could run during system installation and maintain the correct, consistent,
and globally unique MAC address. (Yeah, the way it's supposed to.)

As I wrote before on this thread, this is a problem that was documented and
solved 10 years ago. We really should follow the standard and do it "The
Right Way(tm)". See http://tools.ietf.org/html/rfc2469.

Happy Trails,

Loye Young
Isaac & Young Computer Company
Laredo, Texas
http://start.iycc.net

sadly I can't code C for toffee, but at least there is now an infrastructure for others to make more sophisticated changes without having to reinvent the wheel with dkms config.

Above is some topics of the Brazilian Ubuntu forum...

this bug is turning a block if working with clients... and i'm forced to change my client's to windows... unhapply...

http://ubuntuforums.org/showthread.php?t=973410

http://ubuntuforums.org/showthread.php?t=974382

http://linhost.info/2008/11/how-to-set-a-static-ip-on-ubuntu-810/

http://ubuntuforum-br.org/index.php/topic,42160.0.html

http://ubuntuforum-br.org/index.php/topic,42457.0.html

Sorry to say that this seems worse with jaunty. I've seen it before on laptops, but never on my desktop until now, when a jaunty upgrade triggered it. This machine uses a VIA Rhine II on the motherboard, no other network cards, and it didn't trigger any network card renaming under feisty, gutsy, hardy or intrepid. No hardware has changed. Removing 70-persistent-net.rules and rebooting got the network working again.

is VIA Rhine II the network chip??? could you post lspci -vvv ?
the logic related to detecting and fixing/breaking reversed or invalid mac addresses has changed, so this could well be a regression.

Here's just the ethernet section:

00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] (rev 78)
        Subsystem: ABIT Computer Corp. Device 1421
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 32 (750ns min, 2000ns max), Cache Line Size: 32 bytes
        Interrupt: pin A routed to IRQ 10
        Region 0: I/O ports at e400 [size=256]
        Region 1: Memory at e8101000 (32-bit, non-prefetchable) [size=256]
        Capabilities: <access denied>
        Kernel driver in use: via-rhine

In case I didn't include enough, I'll also attach the whole lspci -vvv output.

i wasn't aware that this chip was associated with this bug.

can you post your "dmesg" output, or just the bit which may or may not say that you have an invalid mac address.
please also post "ifconfig" output, so we can see what your MAC address(es) are right now.

also try the forcedeth module in my ppa, link above. it's very crude, but should work if you are getting an invalid mac being recreated each time.

> i wasn't aware that this chip was associated with this bug.

It wasn't until now. Or do you mean that this bug report is meant to cover only specific chips? From the description and comments I thought it was a generic bug covering 70-persistent-net.rules incrementing incorrectly on any net hardware, but I can move to a different bug (or file a new one)
if you prefer.

I'm attaching the full dmesg log. The part where the net card is initialized and the MAC address printed is:

[ 0.475359] via-rhine: Broken BIOS detected, avoid_D3 enabled.
[ 0.475436] via-rhine.c:v1.10-LK1.4.3 2007-03-06 Written by Donald Becker
[ 0.475512] via-rhine 0000:00:12.0: PCI INT A -> Link[LNKA] -> GSI 10 (level, low) -> IRQ 10
[ 0.479677] eth0: VIA Rhine II at 0xe8101000, 00:50:8d:c0:b9:30, IRQ 10.
[ 0.480447] eth0: MII PHY found at address 1, status 0x786d advertising 05e1 Link 45e1.

ifconfig for the card is:
eth0 Link encap:Ethernet HWaddr 00:50:8d:c0:b9:30
          inet addr:192.168.1.5 Bcast:192.168.1.255 Mask:255.255.255.0
          inet6 addr: fe80::250:8dff:fec0:b930/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
          RX packets:257 errors:0 dropped:0 overruns:0 frame:0
          TX packets:264 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:117439 (117.4 KB) TX bytes:23805 (23.8 KB)
          Interrupt:10 Base address:0x8000

MAC is 00:50:8d:c0:b9:30 in both.

I didn't quite follow the forcedeth discussion earlier in the bug. Isn't forcedeth some kind of nvidia thing? I don't have any nvidia here. Should I try installing forcedeth-dkms anyway?

On Sun, 2009-03-22 at 17:02 +0000, Akkana Peck wrote:

> It wasn't until now. Or do you mean that this bug report is meant to
> cover only specific chips?
>
This bug report only covers the one specific chip that's MAC address
changes each time.

If unsure (as you clearly are, since you note the MAC is the same in
both) it's *ALWAYS* better to file a new bug than jump into an old one.

Since you haven't attached your 70-persistent-net.rules file, it's hard
to tell, but I suspect you're suffering a different bug.

Scott
--
Scott James Remnant
<email address hidden>

I can't find a place to tell whether your MAC address is valid for your chip. forcedeth makes one up in a certain valid sub-range not associated with any hardware. it looks like a valid MAC for some chip. the forcedeth ones all begin with an unusual 00:00 before the random hex, but this is probably just a forcedeth quirk and not approved behaviour.

the crucial question, is whether your MAC address is the same on reboot, or after suspend/resume. The persistent net rules behaviour is consistent with it seeing new devices; the bug is that the same device is given new MAC addresses. If your MAC is changing, you could look at my trivial code changes for forcedeth and apply them to the relevant module. This is probably not as hard as it sounds as I have already hacked together the infrastructure for the most simple imaginable kernel module dkms patch.

I'm not clear whether this bug is especially related to forcedeth behaviour, or just any invalid MAC.

Okay, new bug 346885 filed.

Would it be possible to change the title of this bug to make it clear what chipset(s) it covers? I bet I'm not the only one on the list of subscribers who thought this was a generic bug on this persistent-net.rules behavior.

The MAC address doesn't change. In fact, the two entries, eth0 and eth1, in 70-persistent-net.rules both had the same MAC address (I've attached that file over in bug 346885).

Thanks for the comments!

>I bet I'm not the only one on the list of
>subscribers who thought this was a generic bug on this persistent-
>net.rules behavior.

I'll echo that. I can't see how this bug report is confined to a particular
chipset. We at IYCC see the problem on several hardware configurations.

It's really a generic problem that should be fixed generically.

Loye Young
Isaac & Young Computer Company
Laredo, Texas
http://start.iycc.net

On Mon, 2009-03-23 at 02:27 +0000, Loye Young wrote:

> I'll echo that. I can't see how this bug report is confined to a particular
> chipset. We at IYCC see the problem on several hardware configurations.
>
> It's really a generic problem that should be fixed generically.
>
No, it isn't.

If you think otherwise, please provide patches.

Scott
--
Scott James Remnant
<email address hidden>

On Mon, Mar 23, 2009 at 7:56 AM, Scott James Remnant <email address hidden>wrote:
>If you think otherwise, please provide patches.

I've already written in this thread how to fix the problem, but nobody
seemed to be interested.

Loye Young
Isaac & Young Computer Company
Laredo, Texas
http://start.iycc.net

On Mon, 2009-03-23 at 19:11 +0000, Loye Young wrote:

> On Mon, Mar 23, 2009 at 7:56 AM, Scott James Remnant <email address hidden>wrote:
> >If you think otherwise, please provide patches.
>
> I've already written in this thread how to fix the problem, but nobody
> seemed to be interested.
>
Sorry, you're quite right - and what you posted is correct.

However your statement that the bug is a "generic problem" is generally
wrong, since there is apparently only one Linux driver that behaves in
this way.

(So there's no need for a generic fix)

Scott
--
Scott James Remnant
<email address hidden>

Well, it has been reported for other chipsets -- Realtek and Prism54 (Prism54 apparently fixed by bug 31502). And a few reports here of similar looking problems with different causes, like Oscar Manuel Gómez Senovilla's asix, and my Via-Rhine problem (which you fixed in bug 329106).

It's probably just my unfamiliarity with launchpad, but it's fairly confusing trying to figure out which bug is intended to cover which chipset, and I know I've mistaken chipset-specific bugs (like this one) for more general issues. Maybe mention the chipset in the bug title when it's intended to be specific, so people with other hardware know to look elsewhere? e.g. "forcedeth: Ethernet's MAC address changes ...".

I came across this bug today. At work we are migrating to Ubuntu Lucid 32 bit.
33 machines installed fine, but today, two of them keep changing mac address after every boot.

It's quite annoying that this bug is still present.

This still affects me with my CK804 NVidia onboard ethernet controller. The detected MAC address is NOT correctly reversed back to its correct order. I THINK this means the list of chips to reverse needs updating, but I tried this quickly and it didn't work. I'm attaching a patch just to manually use the reverse of the detected MAC address.

I toyed with DEV_HAS_CORRECT_MACADDR and other flags but no success.

dkms subtree wtih source code and some working compiled kernel modules.