[LEDE-DEV] [PATCH netifd] device: extend interface.macaddr option to refer to another interface

[Guenther Kelleter]

Please see below

> -----Original Message-----
> From: Felix Fietkau [mailto:nbd at nbd.name]
> Sent: Friday, November 4, 2016 3:09 PM
> To: Guenther Kelleter <Guenther.Kelleter at devolo.de>; lede-
> dev at lists.infradead.org
> Subject: Re: [LEDE-DEV] [PATCH netifd] device: extend interface.macaddr
> option to refer to another interface
> 
> On 2016-11-03 13:49, Günther Kelleter wrote:
> > e.g. option macaddr "@eth0" tells netifd to use the MAC of interface eth0.
> > Use case: set MAC address of a bridge interface to a specific interface's
> > MAC regardless of bridge/interface initialization order.
> >
> > Signed-off-by: Günther Kelleter <guenther.kelleter at devolo.de>
> > ---
> >  device.c | 16 +++++++++++++++-
> >  1 file changed, 15 insertions(+), 1 deletion(-)
> >
> > diff --git a/device.c b/device.c
> > index 82596e4..c63ddc7 100644
> > --- a/device.c
> > +++ b/device.c
> > @@ -256,7 +256,21 @@ device_init_settings(struct device *dev, struct
> blob_attr **tb)
> >  	}
> >
> >  	if ((cur = tb[DEV_ATTR_MACADDR])) {
> > -		ea = ether_aton(blobmsg_data(cur));
> > +		const char *data = blobmsg_data(cur);
> > +		struct device_settings ds = {0};
> > +		if (data[0] == '@') {
> > +			struct device dev = {0};
> > +			strncpy(dev.ifname, data + 1, sizeof dev.ifname);
> > +			dev.ifname[sizeof dev.ifname - 1] = '\0';
> > +			system_if_get_settings(&dev, &ds);
> > +			if (ds.flags & DEV_OPT_MACADDR) {
> > +				ea = (struct ether_addr *)ds.macaddr;
> > +			} else {
> > +				ea = NULL;
> > +			}
> > +		} else {
> > +			ea = ether_aton(blobmsg_data(cur));
> > +		}
> I think this is somewhat quirky. Depending on the time when this device
> is brought up, it could either get an original device mac address, or
> one that has been modified via UCI. This is also not taken into account
> on reload.
> 
> What's your use case for this?

The original issue we had was that depending on the initialization order of the interfaces in the bridge, the bridge got different IP addresses from DHCP.
If e.g. bridge consists of eth0 and eth1, the resulting MAC address of the bridge was non-deterministically either eth0's or eth1's MAC address, depending on some (to me) unknown varying initialization order of the eth interfaces. That resulted in different DHCP address assignments.
The extension fixes this so the bridge always gets the same MAC (which is in our case original device MAC addr. Set by the machine init or a boot time fixup).
Using an explicit MAC address in the bridge configuration is not an option for us, since we want to use the same network configuration on different devices (sysupgrade backup -> restore to another device).

Günther

> 
> - Felix