ubuntu-eee-coders team mailing list archive

[Stuart Young <cef@xxxxxxxxx>]

FWIW: The method to reproduce is simple:

1. Boot with a wired network connection and get an IP. Check the MAC
address.

2. Suspend to Ram (using the shutdown dialog and clicking 'suspend' -
aka via the menu, NOT through system hotkeys).

3. Resume.

4. Check interface to see if MAC address changed.

5. Repeat.

Notes:

The Assigned (Adam McDaniel) has been able to reproduce this bug
himself, but I do not know if he has actual hardware, or if it was a
loan unit.

As mentioned, this ONLY affects systems that use the atl1e wired network
driver, which should be the 1000H, and the 901. The 900A afaik uses a
different wired network driver.

I have had much more success actually suspending using the shutdown
dialog than via system hotkeys, and it eliminates any issues that could
be caused by the tools that catch/perform the hotkey actions.

-- 
MAC Address change after suspend (atl1e)
https://bugs.launchpad.net/bugs/271744
You received this bug notification because you are a member of Ubuntu
Eee Coders, which is subscribed to Easy Peasy.

Status in Easy Peasy: New
Status in Ubuntu EeePC-optimized Kernel: Triaged
Status in Ubuntu EeePC Kernel Series: 2.6.24: Confirmed

Bug description:
Occasionally after suspend, the MAC address for the wired network card on a Eee 901/1000/1000h changes to something other than the correct MAC address. I've had this behavior confirmed by 2 other independent sources on IRC (#eeepc on FreeNode).

On a network with DHCP, this results in a new IP address being allocated after a suspend. It also results in the interface name changing, and a bunch of bogus entries being left in /etc/udev/rules.d/70-persistent-net.rules storing the varied MAC addresses that seem to be given to the adapter after this suspend bug.

Note: This does not happen always. I've had it happen irregularly. When trying to directly force it to happen, it took at least 5 suspends in the space of 3 minutes to get it to happen.

Applies to the 2.6.24-21-eeepc kernel and I've had an independent confirmation that the same bug exists in 2.6.24-22-eeepc kernel in the array.org hardy-proposed repository.