History log of /freebsd-10.1-release/share/man/man4/tap.4
Revision Date Author Comments
(<<< Hide modified files)
(Show modified files >>>)
# 272461 02-Oct-2014 gjb

Copy stable/10@r272459 to releng/10.1 as part of
the 10.1-RELEASE process.

Approved by: re (implicit)
Sponsored by: The FreeBSD Foundation

# 256281 10-Oct-2013 gjb

Copy head (r256279) to stable/10 as part of the 10.0-RELEASE cycle.

Approved by: re (implicit)
Sponsored by: The FreeBSD Foundation


# 230580 26-Jan-2012 glebius

Don't mention no longer supported ioctl commands.


# 206622 14-Apr-2010 uqs

mdoc: order prologue macros consistently by Dd/Dt/Os

Although groff_mdoc(7) gives another impression, this is the ordering
most widely used and also required by mdocml/mandoc.

Reviewed by: ru
Approved by: philip, ed (mentors)


# 182881 08-Sep-2008 emax

Document TAPGIFNAME, TAPSIFINFO and TAPGIFINFO tap(4)
character device ioctl's.

MFC after: 1 week


# 167714 19-Mar-2007 bms

Document net.link.tap.up_on_open.

PR: 110383
Submitted by: Frank Behrens
MFC after: 2 weeks


# 166497 04-Feb-2007 bms

Implement ifnet cloning for tun(4)/tap(4).
Make devfs cloning a sysctl/tunable which defaults to on.

If devfs cloning is enabled, only the super-user may create
tun(4)/tap(4)/vmnet(4) instances. Devfs cloning is still enabled by
default; it may be disabled from the loader or via sysctl with
"net.link.tap.devfs_cloning" and "net.link.tun.devfs_cloning".

Disabling its use affects potentially all tun(4)/tap(4) consumers
including OpenSSH, OpenVPN and VMware.

PR: 105228 (potentially also 90413, 105570)
Submitted by: Landon Fuller
Tested by: Andrej Tobola
Approved by: core (rwatson)
MFC after: 4 weeks


# 144979 12-Apr-2005 mdodd

Provide a sysctl (net.link.tap.user_open) to allow unpriviliged
acces to tap(4) device nodes based on file system permission.

Duplicate the 'debug.if_tap_debug' sysctl under the
'net.link.tap' hierarchy.


# 141846 13-Feb-2005 ru

Expand *n't contractions.


# 119893 08-Sep-2003 ru

mdoc(7): Use the new feature of the .In macro.


# 112609 25-Mar-2003 keramida

Delete MAKEDEV references and update the text about /dev/foo control
devices that return the next available device when opened.

PR: 50280, 50281, 50282, 50283
Submitted by: Sergey A.Osokin <osa@FreeBSD.org.ru>


# 107383 29-Nov-2002 ru

mdoc(7) police: scheduled sweep.

Approved by: re


# 94561 12-Apr-2002 trhodes

Make a few content fixes/additions to tap(4) manual page.

PR: 36985
Submitted by: Hiten Pandya <hiten@uk.FreeBSD.org>
MFC after: 4 days


# 83334 11-Sep-2001 ru

mdoc(7) police: removed hard sentence breaks.


# 83077 05-Sep-2001 dd

can not -> cannot


# 83043 04-Sep-2001 brooks

Add cloning support for the tap(4) device similar to that in the tun(4)
device.

Submitted by: Maksim Yevmenkin <myevmenk@digisle.net>


# 81251 07-Aug-2001 ru

mdoc(7) police:

Avoid using parenthesis enclosure macros (.Pq and .Po/.Pc) with plain text.
Not only this slows down the mdoc(7) processing significantly, but it also
has an undesired (in this case) effect of disabling hyphenation within the
entire enclosed block.


# 76175 01-May-2001 schweikh

pseudo-device -> device in kernel config lines. Removed whitespace at EOL.
Reviewed by: joerg, dd


# 71895 01-Feb-2001 ru

mdoc(7) police: split punctuation characters + misc fixes.


# 70466 29-Dec-2000 ru

Prepare for mdoc(7)NG.


# 68962 20-Nov-2000 ru

mdoc(7) police: use the new features of the Nm macro.


# 68716 14-Nov-2000 ru

Use Fx macro wherever possible.


# 64136 02-Aug-2000 nsayer

Minor man page corrections and fixups to document the difference between
tap and vmnet style devices.

Submitted by: Vladimir


# 63670 20-Jul-2000 nsayer

Add the tap driver.

The tap driver is used to present a virtual Ethernet interface to the
system. Packets presented by the network stack to the interface are
made available to a character device in /dev. With tap and the bridge
code, you can make remote bridge configurations where both sides of
the bridge are separated by userland daemons.

This driver also has a special naming hack to allow it to serve a similar
purpose to the vmware port.

Submitted by: myevmenkin@att.com, vsilyaev@mindspring.com