Hi Peter, > >>> 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. > > You can have your userspace check the command line in /proc and set it. > I don't need to have a MAC address passed from u-boot to do that; I can > have it be in a config file on disk. > > Wherever the correct MAC address comes from, I need a user-space program > to set it. I can start that through a udev rule (most natural) or a > systemd service. I need this whether or not connman is used; > NetworkManager and classic ifconfig both still need some way to insert a > configuration step between the point the interface becomes visible and > the point it's brought up at the link layer. (With ifconfig this can be > done through a hwaddr statement in /etc/network/interfaces.) > > What I don't see is a way to coordinate this with connman, which > immediately brings up the eth0 interface as soon as the kernel publishes > its existence regardless of whether it's actually ready to be configured. > > I see several options: > > * I can have the user-space program wait until connman has brought the > interface up, then take the interface back down again, correct its > configuration, and re-enable it;
bad idea actually. You will broadcast the MAC address onto the network. ConnMan will be too fast for you no matter what. > * I could configure connman to not bring up anything named "eth0" > automatically, and instead have the user space program enable it once > it's configured properly; Sounds like a nasty workaround. I do not like this at all. > * I can configure systemd to not start connman until something else has > configured the MAC address. This is most likely the best idea right now. If the system needs some sort of configuration before the network devices are ready, you should delay the start of ConnMan. Another option would be to actually have the kernel not to mark this device as ready until the MAC address is programmed into it. Random addresses are not a good idea to declare as being ready unless they are really meant to be random. If the hardware really comes without an address, then it should stay in an unready state until userspace had a chance to program the address into it. > The first two options would appear to require some sort of scriptable > control of connman. Because the only control interface is through dbus > this isn't easy: most examples I've found are based on python, and it > seems overkill to have to install python just to bring up the network > properly. I do see suggestions in the git repository that someday there > will be a "connmanctl" program which could do this, but it's not part of > the installed system. > > The second alternative also requires a way to tell connman that a wired > interface is to be enabled but not autoconfigured. I haven't found > anything to do that. The documentation (config-format.txt) suggests > that only wifi interfaces support config files. Adding > "AutoConnect=false" to the wired section of /var/lib/connman/settings > had no effect; connman still brought eth0 up. > > The third option is the only semi-reasonable solution I've found that I > believe would be supported by connman today. I was hoping that there > was a better solution that I hadn't found. > > How would this be done if I wanted to statically assign network > configuration data to an interface that had a fixed MAC address? Have > something install /var/lib/connman/ethernet_(macaddr)_cable/settings? We could have ConnMan configure the MAC addresses, but right now I can not see a good way to do so. I am open to suggestions on how this could have been done in a generic and clean way. Regards Marcel _______________________________________________ connman mailing list connman@connman.net http://lists.connman.net/listinfo/connman
