Common storage of original MAC address
John Baldwin
jhb at freebsd.org
Wed Aug 20 16:00:46 UTC 2014
On Monday, August 18, 2014 4:12:23 am Brooks Davis wrote:
> On Sun, Aug 17, 2014 at 11:31:19PM +0000, Pokala, Ravi wrote:
> > Hi folks,
> >
> > At attach-time, the NIC drivers call ether_ifattach(), which stores the
> > MAC address in the sockaddr_dl. If the MAC is subsequently changed (like
> > by adding the interface to a lagg), if_setlladdr() changes the value in
> > the sockaddr_dl. At least, that's the way I'm reading things - is that
> > correct?
> >
> > If so, then we do not keep a copy of the original MAC address. For a
> > couple of reasons (diagnostics, asset tracking and reporting), it would be
> > very nice if the original MAC were kept somewhere, even after the working
> > MAC was changed by if_setlladdr().
> >
> > Up till now, Panasas has been saving the original MAC in the softc of
> > specific network drivers that we use, and making it accessible via a
> > sysctl. That's something we have to do on a per-driver basis, and
> > something we have to keep track of on our own. We'd like to put that
> > information in a structure all the NIC drivers already use, and get that
> > code upstream. Storing it would require a simple change to
> > ether_ifattach() to stash it in the new location in addition to in the
> > sockaddr_dl, and adding some standard way (a new ioctl or sysctl?) to
> > access it. Notably, it would not require changing all the individual
> > drivers.
> >
> > Are there any objections to this idea? Any suggestions as to where we
> > might stash the original MAC?
>
> I think I'd store the original address in struct arpcom at attach time
> and publish it in the dev.<driver>.<unit> sysctl namespace.
ifnets and device_t's aren't necessarily 1:1 (some multiport NIC drivers might
only create a device_t for the adapter).
--
John Baldwin
More information about the freebsd-hackers
mailing list