Bug 118111 - rc: network.subr Add MAC address based interface renaming
Summary: rc: network.subr Add MAC address based interface renaming
Status: In Progress
Alias: None
Product: Base System
Classification: Unclassified
Component: conf (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Some People
Assignee: Kyle Evans
Keywords: easy, feature, needs-qa
Depends on:
Reported: 2007-11-18 23:00 UTC by Thomas Hurst
Modified: 2024-01-10 03:41 UTC (History)
16 users (show)

See Also:
koobs: maintainer-feedback? (net)
grahamperrin: mfc-stable13?

file.diff (1.38 KB, patch)
2007-11-18 23:00 UTC, Thomas Hurst
no flags Details | Diff
file.diff (682 bytes, patch)
2007-11-18 23:00 UTC, Thomas Hurst
no flags Details | Diff
Patch against CURRENT (1.17 KB, patch)
2018-07-13 23:37 UTC, Thomas Hurst
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Hurst 2007-11-18 23:00:04 UTC
I recently temporarily added an additional network card to my system for
testing, thus moving all my interface names about; em0 becomes em1, etc,
necessitating annoying configuration changes and/or cable juggling.

Many Linux distributions solve this problem with /etc/iftab or /etc/mactab,
wiring an interface name to a MAC address so they're no longer dependent on
probe order.

This patch adds similar functionality to network.subr's ifnet_rename function,
so things like the following can be added to rc.conf:

ifconfig_mac_names="lan0 inet0"

Also included is a small patch against the rc.conf(5) manpage.

Both patches are against RELENG_7, but should apply relatively cleanly against
Comment 1 OlivierW 2016-12-18 23:23:52 UTC

It would be nice to have this patch merged as I think it's quite useful :-)

Best Regards
Comment 2 Thomas Hurst 2018-07-13 23:37:54 UTC
Created attachment 195121 [details]
Patch against CURRENT

Since this hasn't had much love lately, I've done a bit of work to update the network.subr patch against CURRENT so at least there's something new to look at.

This patch changes how it works a little - the original example now looks like this:


Not quite as pretty, but the patch is a fair bit simpler now.

Renaming is still pretty rudimentary - it can't reliably pin, say, "em0", because another interface may already have that name, but one step at a time.

Care also needs to be taken if a system is sharing "ether" across multiple interfaces, e.g. with lagg.  hwaddr might be more appropriate in these cases, and this naming scheme helpfully leaves room for that in future.
Comment 3 Kubilay Kocak freebsd_committer freebsd_triage 2019-05-21 03:59:40 UTC
Can't be in progress without an assignee
Comment 4 Chris Hutchinson 2020-10-29 16:24:56 UTC
I have/use several multi-port NIC's where something like this
would be wonderful to have available. It's now been more than
a decade. Any chance we can get this committed before 2030?

A big thanks to everyone involved -- especially Thomas. :-)
Comment 5 Slawomir Wojciech Wojtczak 2020-10-30 18:12:50 UTC
> Any chance we can get this committed before 2030?

Loved that one. Made my day :)
Comment 6 eborisch+FreeBSD 2021-07-13 14:56:51 UTC
The https://www.freshports.org/sysutils/ethname port is available that performs essentially the same function while waiting for 2030. ;)

Required entries in rc.conf:

Comment 7 Santiago Martinez 2021-09-05 23:49:56 UTC
What needs to be done to get this merged? 

If testing is required I can do some.
Comment 8 Slawomir Wojciech Wojtczak 2021-09-06 08:06:38 UTC
One question, has it been tested with lagg(4) interfaces?

Not sure on FreeBSD but on Linux when I had bond0 interface and the scripts 'per interface' had MAC address then they failed because after bond0 was activated/created the network interfaces had MAC addresses changed.

Comment 9 Graham Perrin freebsd_committer freebsd_triage 2022-12-05 01:59:39 UTC
Triage: de-prioritised (this is not a security bug); 
Comment 10 Zhenlei Huang freebsd_committer freebsd_triage 2023-04-20 01:05:02 UTC
I'm proposing a general approach to fix this problem, please see https://reviews.freebsd.org/D39689 .