Ubuntu
linux-mvl-dove package

Ethernet port on the dove sometimes changes MAC addresses

Bug #435046 reported by Michael Casadevall
12
This bug affects 1 person
Affects Status Importance Assigned to Milestone
linux-mvl-dove (Ubuntu)
Expired
Medium
Unassigned
Karmic
Won't Fix
Medium
Unassigned

Bug Description

The ethernet port on the Marvell dove board randomly changes its MAC address; the MAC address remains consistant during run times but can change between restarts. Here's the leases from the DHCP server:

lease 192.168.1.124 {
  starts 3 2009/09/23 04:33:30;
  ends 3 2009/09/23 04:43:30;
  binding state active;
  next binding state free;
  hardware ethernet 00:50:43:6e:0d:1c;
  client-hostname "twilight";
}

lease 192.168.1.125 {
  starts 3 2009/09/23 04:23:47;
  ends 3 2009/09/23 04:33:47;
  tstp 3 2009/09/23 04:33:47;
  binding state free;
  hardware ethernet 00:50:43:3b:3b:01;
}

lease 192.168.1.122 {
  starts 3 2009/09/23 05:32:01;
  ends 3 2009/09/23 05:42:01;
  tstp 3 2009/09/23 05:42:01;
  binding state free;
  hardware ethernet 00:50:43:22:32:15;
}

lease 192.168.1.120 {
  starts 3 2009/09/23 05:43:01;
  ends 3 2009/09/23 05:53:01;
  binding state active;
  next binding state free;
  hardware ethernet 00:50:43:50:02:28;
  client-hostname "twilight";
}

As an addition note, the changes in MAC address seem to collegiate with a change in the ethX device. The first lease was taken when the board said its ethernet device was eth3, the second was taken when it was eth7. The third was 8 or 9 (I forgot to note it), and the fourth was 10th. As an addition data point, u-boot says:
ethaddr=00:50:43:4c:1a:2a

It also has yuk_ethaddr=00:00:00:EE:51:81 set.

I'm unsure what, if any affect these may have on how the MAC comes up.

Michael Casadevall (mcasadevall)
tags: added: armel
Loïc Minier (lool)
Changed in linux-mvl-dove (Ubuntu Karmic):
assignee: nobody → Brad Figg (brad-figg)
milestone: none → ubuntu-9.10
Revision history for this message
Loïc Minier (lool) wrote :

I was told Dove randomises the MAC address on boot to avoid conflicts with other boards; to fix this one is supposed to 'setenv ethaddr < you MAC>; saveenv' in uboot.

Oliver told me Michael can't verify this fix.

Revision history for this message
Loïc Minier (lool) wrote :

Upstream suggests "maybe that's because you are using u-boot on NAND instead of SPI?"

Revision history for this message
Rabeeh Khoury (rabeeh) wrote :

please check -

setenv ethaddr 00:67:81:22:11:33
saveenv
reset
printenv ethaddr

on my u-boot that runs on SPI this works.

Revision history for this message
Rabeeh Khoury (rabeeh) wrote :

Michael,

I was just able to download u-boot from u-art to the DDR using minicom.
This way you will never be able to brick your u-boot on the SPI flash since you can always recreate it.

The process is -
1. Build U-boot for uart configuration. The 512MB configuration worked for me but the 1GB didn't (on u-boot version 4.2.9) - bug was reported and will be fixed in future releases.
2. Open minicom with 115200 8N1 no HW/SW flow controls
3. Modify boot option to boot from uart (dip switch SW7 set to 0xe)
4. Power up the system. The bootrom should send NACK character which is translated as space character on minicom
5. Hold the reset button
6. Send the u-boot in xmodem (Ctrl-A - S, choose xmodem and then file).
7. Release the reset button. Note that the board should stay at reset when starting sending the file.

If after xmodem file send is done and you still get the space characters in minicom (and not u-boot prompt) then it means that checksum on the image failed !!!

After u-boot is booted through uart and loaded to DDR, you can 'bubt' your new brand u-boot but with booting from SPI configuration; resetenv and all other goodies you want.

Michael - please let me know if you want other info on this; or should I post this info on different place.

Revision history for this message
Brad Figg (brad-figg) wrote :

This does not seem to be an issue with the kernel but with the uboot configuration. There is no way for the kernel to guess what the valid mac address should be. However, if the issue is that the kernel is ignoring a valid mac address and instead generating a random one then that would be a kernel bug.

Changed in linux-mvl-dove (Ubuntu Karmic):
assignee: Brad Figg (brad-figg) → Michael Casadevall (mcasadevall)
Revision history for this message
Loïc Minier (lool) wrote :

So am I correct that the issue only pops up when using NAND uboot and that it can be worked around by setting ethaddr in the env in all cases? Can we document this in the dove instructions?

Andy Whitcroft (apw)
Changed in linux-mvl-dove (Ubuntu Karmic):
importance: Undecided → Medium
Revision history for this message
Loïc Minier (lool) wrote :

Michael; please confirm that a documentation fix is enough

Loïc Minier (lool)
Changed in linux-mvl-dove (Ubuntu Karmic):
status: New → Won't Fix
Changed in linux-mvl-dove (Ubuntu):
milestone: ubuntu-9.10 → none
Changed in linux-mvl-dove (Ubuntu Karmic):
milestone: ubuntu-9.10 → none
assignee: Michael Casadevall (mcasadevall) → nobody
Revision history for this message
Loïc Minier (lool) wrote :

Please reopen if this is still a valid bug

Changed in linux-mvl-dove (Ubuntu):
status: New → Incomplete
Jeremy Foshee (jeremyfoshee)
tags: added: kernel-series-unknown
Michael Casadevall (mcasadevall)
Changed in linux-mvl-dove (Ubuntu):
assignee: Michael Casadevall (mcasadevall) → nobody
Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for linux-mvl-dove (Ubuntu) because there has been no activity for 60 days.]

Changed in linux-mvl-dove (Ubuntu):
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.