sysfs: add entry to indicate network interfaces with random MAC address
in [Kernel]
|
Prev: sysfs: add entry to indicate network interfaces with random MAC address
Next: ds2782_battery: Rename get_current and get_voltage operations
From: Stefan Assmann on 20 Jul 2010 07:50 On 20.07.2010 13:20, Ben Hutchings wrote: > On Tue, 2010-07-20 at 12:50 +0200, Stefan Assmann wrote: >> From: Stefan Assmann <sassmann(a)redhat.com> >> >> Reserve a bit in struct net_device to indicate whether an interface >> generates its MAC address randomly, and expose the information via >> sysfs. >> May look like this: >> /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/net/eth0/ifrndmac >> >> By default the value of ifrndmac is 0. Any driver that generates the MAC >> address randomly should return a value to 1. > > The name should incorporate 'address', not 'mac', for consistency with > the generic 'address' attribute. We can call it "ifrndhwaddr" if that's more consistent. > > What about devices that 'steal' MAC addresses from slave devices? > Currently I believe udev has special cases for them but ideally these > drivers would indicate explicitly that their addresses are not stable > identifiers (even though they aren't random). It's really up to the driver to decide whether it makes sense to set the flag or not. The question is what should udev do with these MAC address stealing devices apart from ignoring them? Sorry I have no higher insight into it. This flag has the purpose to allow udev to explicitly handle devices that generate their MAC address randomly and generate a persistent rule based on the device path instead of the MAC address. I'm open for suggestions but I'm not sure we can handle both cases with a single flag. JFYI this is an alternative approach to changing the kernel name of VFs to vfeth. The advantage of this way should be that we don't break any user-space applications that rely on network interfaces being names "ethX". Actually this goes in the direction of "fixing udev" which was what you asked for in your comment on my first patch concering vfeth. :) > > [...] >> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h >> index b626289..2ea0298 100644 >> --- a/include/linux/netdevice.h >> +++ b/include/linux/netdevice.h >> @@ -845,6 +845,7 @@ struct net_device { >> #define NETIF_F_FCOE_MTU (1 << 26) /* Supports max FCoE MTU, 2158 bytes*/ >> #define NETIF_F_NTUPLE (1 << 27) /* N-tuple filters supported */ >> #define NETIF_F_RXHASH (1 << 28) /* Receive hashing offload */ >> +#define NETIF_F_RNDMAC (1 << 29) /* Interface with random MAC address */ > [...] > > This is not really a feature, and we are running out of real feature > bits. Can you find somewhere else to put this flag? Actually Dave Miller suggested to put it there. What other place is there to put it? Stefan -- Stefan Assmann | Red Hat GmbH Software Engineer | Otto-Hahn-Strasse 20, 85609 Dornach | HR: Amtsgericht Muenchen HRB 153243 | GF: Brendan Lane, Charlie Peters, sassmann at redhat.com | Michael Cunningham, Charles Cachera -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Alex Badea on 20 Jul 2010 08:20 Hi, On 07/20/2010 02:47 PM, Stefan Assmann wrote: >> What about devices that 'steal' MAC addresses from slave devices? Might I suggest an attribute such as "address_type", which could report "permanent", "random", "stolen", or something else in the future? My two cents, Alex -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Stefan Assmann on 20 Jul 2010 08:20 On 20.07.2010 13:58, Alex Badea wrote: > Hi, > > On 07/20/2010 02:47 PM, Stefan Assmann wrote: >>> What about devices that 'steal' MAC addresses from slave devices? > > Might I suggest an attribute such as "address_type", which could report > "permanent", "random", "stolen", or something else in the future? In case there's demand for such a multi-purpose attribute I see no reason to object. More thoughts on this? Thanks for your suggestion Alex. Stefan -- Stefan Assmann | Red Hat GmbH Software Engineer | Otto-Hahn-Strasse 20, 85609 Dornach | HR: Amtsgericht Muenchen HRB 153243 | GF: Brendan Lane, Charlie Peters, sassmann at redhat.com | Michael Cunningham, Charles Cachera -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Stefan Assmann on 20 Jul 2010 08:50 On 20.07.2010 14:07, Ben Hutchings wrote: > On Tue, 2010-07-20 at 13:47 +0200, Stefan Assmann wrote: >> On 20.07.2010 13:20, Ben Hutchings wrote: >>> On Tue, 2010-07-20 at 12:50 +0200, Stefan Assmann wrote: >>>> From: Stefan Assmann <sassmann(a)redhat.com> [snip] >> Actually Dave Miller suggested to put it there. What other place is >> there to put it? > > If Dave said that then I'm sure it's OK. > > However, if you define this as an interface flag (net_device::flags; > <linux/if.h>) and add it to the set of changeable flags in > __dev_change_flags(), user-space will be able to clear the flag if it > later sets a stable address. As I said I'm not that knowledgeable about this MAC address stealing thing and I'm assuming that's what you're aiming at. Would you really want/need it to be user-space writable? Currently all I can think of is the scenario where you set a "stable" address that outlasts a reboot so udev might be able to assign it a permanent name after it gets stable. So it might make sense to have it writable, but I'd like to avoid to add unnecessary complexity that may cause errors if it's not necessary. Read-only is simple, just read the flag and deal with it. Btw, the driver itself could also alter the flag. Then we'd have a well defined way of setting a stable address. Stefan -- Stefan Assmann | Red Hat GmbH Software Engineer | Otto-Hahn-Strasse 20, 85609 Dornach | HR: Amtsgericht Muenchen HRB 153243 | GF: Brendan Lane, Charlie Peters, sassmann at redhat.com | Michael Cunningham, Charles Cachera > > Ben. > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Harald Hoyer on 21 Jul 2010 02:30
On 07/20/2010 11:20 PM, David Miller wrote: > From: Stephen Hemminger<shemminger(a)vyatta.com> > Date: Tue, 20 Jul 2010 14:18:16 -0700 > >> No one mentioned that the first octet of an Ethernet address already >> indicates "software generated" Ethernet address. Per the standard, >> if bit 1 is set it means address is locally assigned. >> >> static inline bool is_locally_assigned_ether(const u8 *addr) >> { >> return (addr[0]& 0x2) != 0; >> } > > W00t! > > Indeed, can udev just use that? :-) It already does: see /lib/udev/rules.d/75-persistent-net-generator.rules -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |