[RFC] ifconfig: match by link-level address

[Darcy Buskermolen]

On May 21, 2004 12:04 am, Peter Pentchev wrote:
> On Thu, May 20, 2004 at 10:18:38AM -0700, Brooks Davis wrote:
> > On Thu, May 20, 2004 at 07:29:19PM +0300, Peter Pentchev wrote:
> > > Hi,
> > >
> > > I found out recently that the Linux (or at least recent RedHat) startup
> > > scripts could be configured to not bring up an Ethernet interface
> > > unless it has a specified MAC address.  This, combined with the
> > > wonderful interface renaming functionality recently committed to
> > > -CURRENT, led me to the idea of interface renaming on boot-up, by
> > > hardware addresses - something like 'I don't care how you detected this
> > > network card, or how many others like it are there, but the card with
> > > MAC address
> > > 00:03:0d:08:dc:a7 will be known as sis0int from now on'.
> > >
> > > The main missing piece was the ability to find an interface by MAC
> > > address; hence the attached patch, also available at
> > > http://www.ringlet.net/~roam/bsd-patches/src5/sbin-ifconfig-hwmatch.pat
> > >ch
> > > http://people.FreeBSD.org/~roam/bsd-patches/src5/sbin-ifconfig-hwmatch.
> > >patch
> > >
> > > It teaches ifconfig(8) to treat interface "names" beginning with 'hw-'
> > > as link-level addresses; ifconfig tries to find an interface with this
> > > address and behaves as if its name was specified on the command line:
> > >
> > > [roam at straylight ~/fbsd/r/src/sbin/ifconfig]> ./ifconfig
> > > hw-00:03:0d:08:dc:a7 sis0:
> > > flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
> > > options=8<VLAN_MTU>
> > >         inet 10.0.8.129 netmask 0xffff0000 broadcast 10.0.255.255
> > >         inet 192.168.1.13 netmask 0xffffff00 broadcast 192.168.1.255
> > >         ether 00:03:0d:08:dc:a7
> > >         media: Ethernet autoselect (100baseTX <full-duplex>)
> > >         status: active
> > > [roam at straylight ~/fbsd/r/src/sbin/ifconfig]>
> > >
> > > This could be the first step towards teaching rc.conf about something
> > > like network_interfaces_rename="hw-00:03:0d:08:dc:a7 sis0int"
> > >
> > > I had initially written my own function for parsing the user-supplied
> > > address into a sequence of bytes instead of using ether_aton(); it
> > > would have the advantage of being able to specify 'hw-' to match lo0's
> > > empty link-level "address".  However, the odds of somebody actually
> > > wishing to rename lo0 don't seem to be so high :)
> >
> > I don't really like the idea of adding magic values to the interface
> > namespace that only work with ifconfig.  If you want ifconfig to match
> > the lladdr, I'd suggest adding a flag that means match interface by
> > address instead of by name.  That would be a fairly simple change to
> > your patch and seems like a potentialy useful feature.
>
> Agreed, I don't like the magic hw- too much either, but.. see below for
> more comments on this and interface renaming on startup.
>
> > FWIW, I've talked to Warner about automaticly renaming interfaces based
> > on things like their MAC address or their PCI slot and we think devd
> > will eventually be the place to do this.  We're probably going to have
> > to rethink interface configuration for this to work though.
>
> Well, it turned out that adding basic interface renaming support to our
> startup scripts wasn't all that hard - the attached patch, also at
> http://www.ringlet.net/~roam/bsd-patches/src5/etc-iface-rename.patch
> http://people.FreeBSD.org/~roam/bsd-patches/src5/etc-iface-rename.patch
> seems to work for both 'sis0 ethlocal xl0 ethext' and
> 'hw-00:03:0d:08:dc:a7 ethlocal', since it just passes the interface name
> to ifconfig(8).
>
> If the link-level address matching should be done with a separate
> ifconfig(8) option, the interface renaming may need to be split into two
> stages controlled by two configuration variables - one specifying the
> 'source' interface by name, the other one by address, with the latter
> code using the new ifconfig option.
>
> Of course, this still leaves a problem with specifying the address for
> an interface that has not yet been 'found' - after all, we can't
> ifmaybeload() a driver on just the link-level address of the card.  This
> is a case when devd might be a better solution indeed.  However, I don't
> think that people who use interface renaming will depend on the system
> automatically discovering the *types* of network cards: if you know the
> MAC address of the card, you'll probably know just what brand and model
> it is, too :)
>
> G'luck,
> Peter

Sorry for the full quote, but it's been a while since this topic was in the 
discusions.

What was the final outcome of rc.conf based interface renaming? I can't find 
any mention of it in rc.conf(5) man pages or other documentation sources.


-- 
Darcy Buskermolen
Wavefire Technologies Corp.
ph: 250.717.0200
fx:  250.763.1759
http://www.wavefire.com