Re: TEST PLEASE: if_tun patch
On Tue, Sep 30, 2003 at 03:17:05PM -0700, Brooks Davis wrote: 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. I like to have all tun/tap interfaces to exist on my system, whether they are opened or not. Interface list is constant, what makes me and my stats more happy, same about firewall rules (rc.d/ppp calls ipfilter resync for example, this would be a bit inconvenient to do the same for 20 /dev/tun). I would like my tun/tap interface *not to* disappear entirely when device is closed, uless I manually do something like ifconfig tun0 destroy. :) 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. Sounds very sensible. -- Pawe Maachowski ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: TEST PLEASE: if_tun patch
On Sun, Sep 28, 2003 at 10:04:42PM -0700, Brooks Davis wrote: 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 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: (1)ttyp4 [~]ifconfig tap19 tap19: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 inet 10.19.0.1 netmask 0xff00 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=8842BROADCAST,RUNNING,SIMPLEX,MULTICAST 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=8842BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 ether 00:bd:69:94:00:13 I have no idea if it works. ;) [screenshot from 4.x, I have no 5.x at this moment] 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. concerned that this destroy on last close semantic will make it harder to implement that. I guess if we moved to a model where we allowed both methods to work, we could somehow add an extra reference when we cloned interfaces via ifconfig if create, but I don't know the devfs side well enough to know if that's possible. -- Pawe Maachowski ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: TEST PLEASE: if_tun patch
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: 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 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: (1)ttyp4 [~]ifconfig tap19 tap19: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 inet 10.19.0.1 netmask 0xff00 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=8842BROADCAST,RUNNING,SIMPLEX,MULTICAST 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=8842BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 ether 00:bd:69:94:00:13 I have no idea if it works. ;) [screenshot from 4.x, I have no 5.x at this moment] 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 -- 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 pgp0.pgp Description: PGP signature
Re: TEST PLEASE: if_tun patch
On Mon, Sep 29, 2003 at 07:29:08AM +0200, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Brooks Davis writes: | Properly dismantle and remove the interface and destroy the dev_t=20 | at last close of the device. 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 totally don't-care on the semantics of any and all of these, my patch is just an attempt to evict makedev() from the tree. If you have a better idea how to do this, by all means go for it. I'd say that for tun devices, the new symantics are probably good. We can worry about supporting interface cloning on them later. -- Brooks -- 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 pgp0.pgp Description: PGP signature
Re: TEST PLEASE: if_tun patch
On Sat, Sep 27, 2003 at 11:57:19PM +0200, Poul-Henning Kamp wrote: Please test this patch: http://phk.freebsd.dk/patch/if_tun.patch There is a slight change in semantics in that the interface will disappear entirely when the /dev/tun%d device is closed. If no objections this will be committed in some days. | Properly dismantle and remove the interface and destroy the dev_t | at last close of the device. 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 concerned that this destroy on last close semantic will make it harder to implement that. I guess if we moved to a model where we allowed both methods to work, we could somehow add an extra reference when we cloned interfaces via ifconfig if create, but I don't know the devfs side well enough to know if that's possible. This doesn't constitute an objection since I've had over a year to fix these drivers, but I'd appreciate it if you would give it some thought. -- Brooks P.S. Since you're moving it anyway, we make the assumption in the network code that the ifnet struct is the first member of the softc so you might want to fix tun while you're there. See the comment around if_var.h:111. -- 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 pgp0.pgp Description: PGP signature
Re: TEST PLEASE: if_tun patch
In message [EMAIL PROTECTED], Brooks Davis writes: | Properly dismantle and remove the interface and destroy the dev_t=20 | at last close of the device. 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 totally don't-care on the semantics of any and all of these, my patch is just an attempt to evict makedev() from the tree. If you have a better idea how to do this, by all means go for it. It has also been pointed out that my subsequent if_tap.c patch would likely break the way people expect the vmnet device to work so I have already canned that. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
TEST PLEASE: if_tun patch
Please test this patch: http://phk.freebsd.dk/patch/if_tun.patch There is a slight change in semantics in that the interface will disappear entirely when the /dev/tun%d device is closed. If no objections this will be committed in some days. | Remove the bogus tunbasedev, instead record the dev_t in our softc. | | Rely on the new an cloning friendlier semantics of make_dev(). | | Properly dismantle and remove the interface and destroy the dev_t | at last close of the device. | | Remove code from MOD_UNLOAD to dismantle things. | | Remove the list used to hang the tunnels from, it is no longer needed. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
