I mentioned in an earlier post that Ubuntu 11.04 is somehow keeping the NIC's MAC address persistent despite the lack of an EEPROM. I investigated a bit and found it was a simple combination of (1) setting a MAC address in the NetworkManager settings and (2) this driver patch going into the latest upstream kernels: smsc95xx: generate random MAC address once, not every ifup.
Back in Fedora 13, I upgraded to David Marlin's latest 2.6.39-1.01.fc13.armv7l kernel from http://people.redhat.com/dmarlin/packages/FedoraArm/ — which includes the above patch — and booted the PandaBoard.
The first thing I noticed was that the NIC is named eth0 now instead of usb0 (that's a nice touch) and, as expected, it has a new random MAC address:
[root@fedora-arm ~]# ifconfig -a
eth0 Link encap:Ethernet HWaddr 4E:19:68:14:3C:F9
BROADCAST MULTICAST MTU:1492 Metric:1
...I changed the MAC address using the standard tools and it appeared to stick:
[root@fedora-arm ~]# ifconfig eth0 hw ether CA:BC:15:4D:B4:49
[root@fedora-arm ~]# ifconfig eth0
eth0 Link encap:Ethernet HWaddr CA:BC:15:4D:B4:49
BROADCAST MULTICAST MTU:1492 Metric:1
...I wanted to make this survive a reboot, so I looked at the /etc/sysconfig/network-scripts/ifup-eth script and found this chunk:
# this isn't the same as the MAC in the configuration filename. It is
# available as a configuration option in the config file, forcing the kernel
# to think an ethernet card has a different MAC address than it really has.
if [ -n "${MACADDR}" ]; then
ip link set dev ${DEVICE} address ${MACADDR}
fi(The ip command is preferred over the older ifconfig command.)
So, I edited /etc/sysconfig/network-scripts/ifcfg-eth0 and removed the HWADDR variable and set MACADDR instead:
DEVICE=eth0
BOOTPROTO=static
ONBOOT=yes
MACADDR=CA:BC:15:4D:B4:49
TYPE=Ethernet
IPADDR=192.168.1.2
NETMASK=255.255.255.0
GATEWAY=192.168.1.1I rebooted the PandaBoard and it worked:
Welcome to Fedora
Press 'I' to enter interactive startup.
Starting udev: [ OK ]
Setting hostname fedora-arm: [ OK ]
...
fedora-arm login: root
Password:
Last login: Thu Jul 14 16:48:49 on console
[root@fedora-arm ~]# ifconfig eth0 | grep HWaddr
eth0 Link encap:Ethernet HWaddr CA:BC:15:4D:B4:49Hooray for persistent MAC addresses!
Actually, the ubuntu kernel uses the die id from the soc to generate a unique mac address. So far, it has been consistent and mostly unique in my setup of 6 pandas (one appears to have a duplicate die id of a prerelease panda).
ReplyDeleteAnd now, so does u-boot with pxe support. I now have my pool of pandas booting w/o any SD cards (use omap4boot to push u-boot.bin).
Looking at the Natty kernel source, I don't see where it's generating the MAC off the die id.
ReplyDeleteI found this upstream patch that adds a new omap_get_die_id() function:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=2e130fc3d4fd5b38ee5d3c0a5c7f9fb85bce698e
And I see the new omap_get_die_id() function is in the Natty kernel:
http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-natty.git;a=blob;f=arch/arm/mach-omap2/id.c;h=5f9086c65e48262835a39d3c7c86b000eba543dd;hb=HEAD#l108
However, I do not see any calls to the omap_get_die_id() function in the smsc95xx.c driver:
http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-natty.git;a=blob;f=drivers/net/usb/smsc95xx.c;h=bc86f4b6ecc218289bad5889ffce90e6e57c27cd;hb=HEAD
There was a proposed patch for the BeagleBoard xM to use the omap_get_die_id() function when generating a MAC address, but this patch does not appear to have been accepted upstream:
http://groups.google.com/group/beagleboard/browse_thread/thread/92d41bb344f8939b?fwc=1
Can you point to where it's using the die id to generate the MAC address? Maybe I'm looking in the wrong place.