From owner-freebsd-current@FreeBSD.ORG Tue Sep 30 15:17:30 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BCB6416A4C0 for ; Tue, 30 Sep 2003 15:17:30 -0700 (PDT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 37C6043F93 for ; Tue, 30 Sep 2003 15:17:27 -0700 (PDT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (IDENT:brdavis@localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.12.9/8.12.3) with ESMTP id h8UMH5DH028846; Tue, 30 Sep 2003 15:17:05 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.12.9/8.12.3/Submit) id h8UMH5DR028845; Tue, 30 Sep 2003 15:17:05 -0700 Date: Tue, 30 Sep 2003 15:17:05 -0700 From: Brooks Davis To: Pawel Malachowski Message-ID: <20030930221705.GC14082@Odin.AC.HMC.Edu> References: <92028.1064699839@critter.freebsd.dk> <20030929050442.GA20995@Odin.AC.HMC.Edu> <20030930213534.GA26486@shellma.zin.lublin.pl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lCAWRPmW1mITcIfM" Content-Disposition: inline In-Reply-To: <20030930213534.GA26486@shellma.zin.lublin.pl> User-Agent: Mutt/1.5.4i X-Virus-Scanned: by amavisd-milter (http://amavis.org/) on odin.ac.hmc.edu cc: freebsd-current@freebsd.org Subject: Re: TEST PLEASE: if_tun patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2003 22:17:31 -0000 --lCAWRPmW1mITcIfM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 30, 2003 at 11:35:34PM +0200, Pawel Malachowski wrote: > On Sun, Sep 28, 2003 at 10:04:42PM -0700, Brooks Davis wrote: >=20 > > I'm not convinced this is the right direction to move in. The problem > > is that users are beginning to expect that pseudo-interfaces be created > > with network interface cloning, but tun, tap, and vmnet aren't. I'm >=20 > Same about ef(4) pseudo-interfaces. > Another thing is that someone may want to create vlan(4) and ef(4) > pseudo-interfaces on tap(4) interface, like this: >=20 > (1)ttyp4 [~]>ifconfig tap19 > tap19: flags=3D8843 mtu 1500 > inet 10.19.0.1 netmask 0xffffff00 broadcast 10.19.0.255 > inet6 fe80::2bd:69ff:fe94:13%tap19 prefixlen 64 scopeid 0x13 > ether 00:bd:69:94:00:13 > (2)ttyp4 [~]>ifconfig vlan0 create > (3)ttyp4 [~]>ifconfig vlan0 vlan 123 vlandev tap0 > (4)ttyp4 [~]>ifconfig vlan0 > vlan0: flags=3D8842 mtu 1496 > ether 00:bd:68:94:00:00 > vlan: 123 parent interface: tap0 > (5)ttyp4 [~]>kldload if_ef > (6)ttyp4 [~]>ifconfig tap19f2 > tap19f2: flags=3D8842 mtu 1500 > ether 00:bd:69:94:00:13 >=20 > I have no idea if it works. ;) > [screenshot from 4.x, I have no 5.x at this moment] >=20 > It looks strange to have `ifconfig create' vlan interface on tap, > while tap uses different semantics and can disappear after closing it? > With ef it is even worse, pseudo-devices are created while ef is > starting, so ef module must be loaded after creating every ethernet > device. That's really evil. :-) The proper fix for the vanishing tap is probably some standard way for parents to know who their children are so they can hunt then down and notify them that they are being orphaned when they die. What the device would do it up to it since some devices like vlan and ef devices might as well die off, but an etherchannel device should just stop sending things to that interface. For ef, I'm thinking of expanding cloning so that we pass the requested name to each cloner for tasting and it decides if it can do that. Then vlans would be created and configured by doing something like: ifconfig fxp0.10 create and you could come up with a similar syntax for ef by appending f# to any ethernet's name to get the appropriate frame interface. A corrected form of the existing behavior could easily be implemented in userland by devd. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --lCAWRPmW1mITcIfM Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE/egDfXY6L6fI4GtQRAmgbAKCtXpm3ASubfklPhNI47JXZyyZglgCg2s3b h/Y6FtWYosPF3zjhnp7rHkw= =+8Sg -----END PGP SIGNATURE----- --lCAWRPmW1mITcIfM--