#
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
|