Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 05 Oct 2019 09:05:10 +0000
From:      bugzilla-noreply@freebsd.org
To:        net@FreeBSD.org
Subject:   [Bug 219746] if_tuntap(4): Renaming (ifconfig(8)) tap(4) misses its character special device name
Message-ID:  <bug-219746-7501-L3W2nED0u6@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-219746-7501@https.bugs.freebsd.org/bugzilla/>
References:  <bug-219746-7501@https.bugs.freebsd.org/bugzilla/>

next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D219746

Kubilay Kocak <koobs@FreeBSD.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
              Flags|                            |mfc-stable11?,
                   |                            |mfc-stable12?
            Summary|Renaming (ifconfig(8))      |if_tuntap(4): Renaming
                   |tap(4) misses its character |(ifconfig(8)) tap(4) misses
                   |special device name         |its character special
                   |                            |device name

--- Comment #2 from Kubilay Kocak <koobs@FreeBSD.org> ---
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 ma=
ke
  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_drive=
r.

  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 clear=
ly
  not that disastrous, but we can't and won't create a /dev for that.

--=20
You are receiving this mail because:
You are on the CC list for the bug.=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-219746-7501-L3W2nED0u6>