On 12/07/2012 04:15 PM, Jack Mitchell wrote:
On 12/07/12 18:06, Peter A. Bigot wrote:
I'm using OpenEmbedded (danny) on a BeagleBoard-xM which has an
on-board USB (SMSC9514) ethernet controller. There is no EEPROM
containing a MAC address, so the kernel (Linux 3.2.28) assigns a
random one.
I'm trying to figure out how to coordinate a user-level override to a
specific MAC address with connman bringing the interface up. The most
successful way I've found to assign the MAC address is to have a udev
rule which runs a script to do the assignment when the device is
discovered.
The problem is that on boot systemd is starting connman at the same
time as the rules are running, and by the time the udev rule command
runs connman may have already grabbed the interface and brought it up
with the random MAC address. If the interface is already up,
invoking "ip link set" from the udev rule fails.
What is the recommended way to ensure connman brings up eth0 with the
correct mac address? Can it be accomplished using connman 1.4 which
is the version available on the current OpenEmbedded Core stable
release branch?
Thanks.
Peter
_______________________________________________
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman
I believe you can set the MAC address from the bootloader if this is
an option?
AFAIK you can't. In earlier versions of OpenEmbedded the kernel (3.0.0
at the time) had been patched to provide the MAC address through a
module parameter, but the patch was rejected upstream and is no longer
part of the openembedded build. I'm unaware of any other way to
communicate the information between u-boot and the kernel; the device
doesn't even exist in the kernel's view until the usb probe finds it and
the corresponding module is loaded from disk, so there's no persistence.
This is somewhat similar to the thread
http://www.mail-archive.com/connman@connman.net/msg09772.html except
that this driver generates a random MAC address rather than a zeroed
one, so there isn't even a clue connman can use to determine that the
interface should not be brought up. In more recent kernels there's a
least a flag (addr_assign_type) that can be consulted to determine that
the address was generated randomly, but that doesn't help with the
current stable release. Even there, the options would be to have
connman leave the interface disabled until it's properly configured, or
provide a hook that connman invokes prior to bringing up the interface
so the MAC address can be validated.
Peter
_______________________________________________
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman
