Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 02 Mar 2024 15:35:02 +0000
From:      bugzilla-noreply@freebsd.org
To:        standards@FreeBSD.org
Subject:   [Bug 277435] [Feature request] Add an option to destroy the tap/tun interface when the descriptor is closed
Message-ID:  <bug-277435-99@https.bugs.freebsd.org/bugzilla/>

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

            Bug ID: 277435
           Summary: [Feature request] Add an option to destroy the tap/tun
                    interface when the descriptor is closed
           Product: Base System
           Version: Unspecified
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: standards
          Assignee: standards@FreeBSD.org
          Reporter: monsterovich@gmail.com

When developing the tap library, I ran into the problem that you cannot des=
troy
an interface (ex. tap0) while the application is running (via SIOCIFDESTROY=
).

The ioctl(SIOCIFDESTROY) call will simply hang until the application using =
this
descriptor finishes (see
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D242841#c0).

Opening "/dev/tap" does not check if existing interfaces are being used and
creates tap(N+1) every time.

It would be nice to make a parameter that will control the automatic
destruction of the interface when the descriptor is closed.

For example:

if (ioctl(fd, TAPSIFDCLOSE, 1) < 0) {
    printf("error: ioctl(TAPSIFDCLOSE)\n");
}

close(fd);

This mechanism is implemented by default in the Linux driver for tuntap:

"A network device will appear as tunXX or tapXX, depending on the options
chosen. When the program closes the file descriptor, the network device and=
 all
corresponding routes will disappear."

Source: https://docs.kernel.org/networking/tuntap.html

--=20
You are receiving this mail because:
You are the assignee for the bug.=



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