Bug 219746 - if_tuntap(4): Renaming (ifconfig(8)) tap(4) misses its character special device name
Summary: if_tuntap(4): Renaming (ifconfig(8)) tap(4) misses its character special devi...
Status: In Progress
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: 11.0-STABLE
Hardware: Any Any
: --- Affects Some People
Assignee: Kyle Evans
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-06-03 06:17 UTC by Harald Schmalzbauer
Modified: 2019-10-05 09:05 UTC (History)
4 users (show)

See Also:
koobs: mfc-stable11?
koobs: mfc-stable12?


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Harald Schmalzbauer 2017-06-03 06:17:51 UTC
Not sure if it's kern/ or bin/, both are involved I guess.

Renaming vmnet/tap(4) interfaces, defined in rc.conf(5) via
"cloned_interfaces" e.g, isn't prohibited by rc(8)-network.subr nor by
ifconfig(8).
If such a interface is renamed, the Ethernet device shows up correctly,
with the new name and ifconfig(8) also reports the new name if it's
created and renamed in the same invocation.
Problem is, the control device isn't renamed, it will keep it's initial
creation name like tap0 and I found no userland way to determine the
corresponding Ethernet IF name.

-harry
Comment 1 Kyle Evans freebsd_committer 2019-04-25 18:04:43 UTC
Take... I could see some use in creating an alias for it, but I'd like to see how this usually works in other OS.
Comment 2 Kubilay Kocak freebsd_committer freebsd_triage 2019-10-05 09:05:10 UTC
Author: kevans
Date: Thu Oct  3 17:54:00 2019
New Revision: 353057
URL: https://svnweb.freebsd.org/changeset/base/353057

Log:
  if_tuntap: create /dev aliases when a tuntap device gets renamed

  Currently, if you do:

  $ ifconfig tun0 create
  $ ifconfig tun0 name wg0
  $ ls -l /dev | egrep 'wg|tun'

  You will see tun0, but no wg0. In fact, it's slightly more annoying to make
  the association between the new name and the old name in order to open the
  device (if it hadn't been opened during the rename).

  Register an eventhandler for ifnet_arrival_events and catch interface
  renames. We can determine if the ifnet is a tun easily enough from the
  if_dname, which matches the cevsw.d_name from the associated tuntap_driver.

  Some locking dance is required because renames don't require the device to
  be opened, so it could go away in the middle of handling the ioctl, but as
  soon as we've verified this isn't the case we can attempt to busy the tun
  and either bail out if the tun device is dying, or we can proceed with the
  rename.

  We only create these aliases on a best-effort basis. Renaming a tun device
  to "usbctl", which doesn't exist as an ifnet but does as a /dev, is clearly
  not that disastrous, but we can't and won't create a /dev for that.
Comment 3 Kubilay Kocak freebsd_committer freebsd_triage 2019-10-05 09:05:52 UTC
If this can/should goto releng/12.1, please set bug 240700 in this issues Blocks field