Hi Matthias, On Fri, Apr 18, 2014 at 1:08 AM, Matthias Schiffer <mschif...@universe-factory.net> wrote: > On 04/18/2014 12:14 AM, Matthias Schiffer wrote: >> On 04/17/2014 11:28 PM, Dave Reisner wrote: >>> On Thu, Apr 17, 2014 at 11:02:11PM +0200, Matthias Schiffer wrote: >>>> Hi, >>>> I'd like to configure the MAC address of a bridge device statically (as >>>> bridges tend to change their MAC address depending on the order the >>>> ports are added on Linux otherwise), but there doesn't seem to be a way >>>> to match for a bridge in a .link unit. This would be very useful for >>>> macvlans as well. >>> >>> Link files can match bridges generally with Type=bridge or Driver=bridge >>> in the [Match] section, or more specifically by just matching on name. >>> In the [Link] section, MACAddressPolicy=persistent should give you >>> persistent hw addresses in the general case, or you can use >>> MACAddress=fe:ed:fa:ce:be:ef to set whatever you like for more specific >>> matches. >>> >>> Does this not work for you? >> Hmm, I thought I tried that before, but using >> MACAddress=fe:ed:fa:ce:be:ef seems to work now. Please note that the >> Name= match is not documented in the systemd.link manpage. > > I have to correct myself: The Name= match does not exist for .link > units. My testcase just seemed to work as a [Match] section only > consisting of a Name= match was considered an empty [Match] section and > matched on all devices... > > This should really be added as AFAICT there is currently no way to match > on virtual devices like briges, TAP devices, batman-adv devices, etc... > which have neither a persistent MAC address nor an ID_PATH to match on.
So I think what we should do here is to allow MAC address (and other things) to be set when creating the netdevs. I made an attempt at this by generating a "predictable" one based on the interface name and the machine-id. Would that do it for you, or are you after a _specific_ mac address, rather than just one that is always the same? I had to revert the code doing this for now as there was a kernel bug, however we'll hopefully get that sorted soon and then get back to this. Cheers, Tom _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
