Bug 212480 - [NEW PORT] sysutils/ethname: boot-time (re)naming of ethernet devices by MAC address.
Summary: [NEW PORT] sysutils/ethname: boot-time (re)naming of ethernet devices by MAC ...
Status: In Progress
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-ports-bugs mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-09-08 05:08 UTC by eborisch+FreeBSD
Modified: 2018-07-29 11:36 UTC (History)
5 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description eborisch+FreeBSD 2016-09-08 05:08:45 UTC
I've put together a rc.d script [1] for renaming ethernet devices at boot time, keeping MAC address <-> devname mappings consistent.

This isn't typically needed on PCIe systems, but for systems with multiple USB ethernet (ue) devices, which seem to like to come up in non-deterministic order, it is very helpful; doubly so when the system in question is a router / firewall where the network config and security concerns vary wildly from one device to the next.

It could also be of use for traditional NICs (PCIe) when adding a new card to a system, for example, and ensuring that the existing, previously configured device sticks to the MAC address, and not having to worry about which ends up /dev/xxxN vs /dev/xxxM.

The script inserts itself before netif, waits an adjustable delay for the expected devices to appear, and then renames them as requested by the user. All of the device configuration, pf, etc., can be written with the new names. It does not attempt to automatically handle devices added after boot.

Perhaps there is some other (pre-existing) way to handle this, but all of the Google-fu I've thrown at it returns "you could write a script to rename then at boot" ... so I did. If there is a simple knob I've missed, please point me at it close this at.

It came up recently [2] in freebsd-stable, and a suggestion was made to file a PR for either base / port inclusion, so here we are.

Having never gone through the process here before, please let me know if there are any changes I can make on my end to accommodate this. As the installation is placement of a single rc.d script, I don't have any installation scripts currently in place. 

[1] https://github.com/eborisch/ethname
[2] https://lists.freebsd.org/pipermail/freebsd-stable/2016-September/085479.html
Comment 1 Nikolai Lifanov freebsd_committer 2017-01-24 16:01:03 UTC
take
Comment 2 Nikolai Lifanov freebsd_committer 2017-01-24 16:14:03 UTC
Would you like this as a port or would you prefer this in base?
Comment 3 eborisch+FreeBSD 2017-01-24 16:23:04 UTC
My initial reaction would be ports. If enough people use it and decide it's the best thing since sliced bread, it can always be moved into base.

That said, I'll defer to your judgement.
Comment 4 eborisch+FreeBSD 2017-03-10 03:29:59 UTC
This tool was mentioned on the BSDNow podcast. Alan mentioned in passing avoiding a config file and doing it all in rc. Seemed like a good idea, so I did it.
Comment 5 Thomas Hurst 2017-04-14 23:00:16 UTC
See also my PR from 2007, trying to get similar functionality in base: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=118111

There I added to the existing /etc/network.subr ifnet_rename() function, which is called from /etc/rc.d/netif start.
Comment 6 Nikolai Lifanov freebsd_committer 2017-04-17 14:19:18 UTC
I'll take a look at it. Thanks!
Comment 7 w.schwarzenfeld freebsd_triage 2018-02-10 15:24:46 UTC
ping!
Comment 8 Nikolai Lifanov freebsd_committer 2018-02-12 13:59:39 UTC
Hi! Thanks for the ping. This one slipped through the cracks.
Comment 9 eborisch+FreeBSD 2018-02-12 15:54:14 UTC
If the desire is to move this functionality into base, Thomas's patch in bug #118111 is likely the right way to go -- integrated as part of netif, as opposed to a precursor to netif.
Comment 10 Farid 2018-07-03 08:03:10 UTC
What is the status of this one?
I'm in the exact same situation as Thomas Hurst in bug #18111.
Comment 11 Thomas Hurst 2018-07-13 23:42:23 UTC
I've just updated #118111 with a patch that applies against CURRENT.