Re: ifconfig tun(N) destroy does not work !

From: Brooks Davis <brooks_at_one-eyed-alien.net>
Date: Tue, 6 Sep 2005 11:57:57 -0700
On Tue, Sep 06, 2005 at 01:49:52PM +0100, Robert Watson wrote:
> On Mon, 5 Sep 2005, Stay d wrote:
> 
> >maybe I havenīt read something what I souhld read it, and if it is true 
> >I am sorry for anoying you.
> >
> >Let me ask you for tun devices.
> >
> >roztyly# ifconfig tun1 destroy
> >ifconfig: SIOCIFDESTROY: Invalid argument
> >
> >I found out from manual page tun(4) that:
> >
> >"These network interfaces persist until the if_tun.ko module is unloaded 
> >(if tun is built into your kernel, the network interfaces cannot be 
> >removed)."
> >
> >Of course the generic kernel defines "device tun", so I commented the 
> >line and recompiled the kernel.
> >
> >After that, I tried again "destroy command" and with no changes.
> >
> >I tried "create command" and the same error message happens.
> 
> Your observation is correct: unlike most clonable network device drivers, 
> tun and tap interface cloning is driven by devfs events, and not by 
> network interface clone events controlled using ifconfig create/destroy.
> 
> I was actually bumping into this yesterday since I wanted to force the 
> garbage collection of a tap device in order to try to trigger a kernel bug 
> involving interface removal, and there is currently no explicit way to do 
> this.  devfs will reclaim the tap device node, if unused, when vnode 
> pressure requires that new vnodes become available.  I.e., when memory use 
> starts to go up, the unused tun and tap nodes will be recycled as needed. 
> Until that time, the device node and network interface will hang around in 
> case needed.  A tun/tap node and interface will be created as a result of 
> a lookup in /dev.  I.e., stat /dev/tun10.
> 
> In a number of ways, I prefer the explicit cloning behavior to implicit -- 
> i.e., might prefer it if explicit "ifconfig create tap0" caused the device 
> node to appear.  On the other hand, one nice advantage to the devfs 
> cloning model is that you can make a /dev/tun automatically return the 
> first unused node, rather than requiring a sweep through node numbers and 
> explicit allocation and management of interface numbers, which is very 
> nice from the perspective of automated configuration.

The implicit cloning of tun devices should go away, but it's not
something I've looked at in detail.  In the past I've looked at it with
the idea of preserving current behavior as well as keeping the current
support and that made things difficult enough that I gave up since it's
a personal priority.  I think the better approach would be to cleanly
implement standard cloning and then bolt a compatability layer on top
of that.  FYI, explicit cloing supports "give me the next one", just do
"ifconfig gif create" and ifconfig will output the name of the newly
created device for use in your script.  A similar thing can be done in a
program that want's to use this feature.

-- Brooks

> Robert N M Watson
> 
> >
> >roztyly# kldstat
> >Id Refs Address    Size     Name
> >1    9 0xc0400000 5bb9fc   kernel
> >2   16 0xc09bc000 63f04    acpi.ko
> >3    1 0xc1848000 23000    nfsserver.ko
> >4    1 0xc18b0000 1a000    linux.ko
> >6    1 0xc2926000 5000     if_gif.ko
> >
> >roztyly# ifconfig tun10 create
> >ifconfig: SIOCIFCREATE: Invalid argument
> >
> >roztyly# kldstat
> >Id Refs Address    Size     Name
> >1   10 0xc0400000 5bb9fc   kernel
> >2   16 0xc09bc000 63f04    acpi.ko
> >3    1 0xc1848000 23000    nfsserver.ko
> >4    1 0xc18b0000 1a000    linux.ko
> >6    1 0xc2926000 5000     if_gif.ko
> >7    1 0xc2910000 5000     if_tun.ko
> >
> >It seems automatic loading if_tun.ko and if_gif.ko works well.
> >
> >Opposite to tun device is gif device which works fine:
> >
> >roztyly# kldstat
> >Id Refs Address    Size     Name
> >1   10 0xc0400000 5bb9fc   kernel
> >2   16 0xc09bc000 63f04    acpi.ko
> >3    1 0xc1848000 23000    nfsserver.ko
> >4    1 0xc18b0000 1a000    linux.ko
> >6    1 0xc2926000 5000     if_gif.ko
> >7    1 0xc2910000 5000     if_tun.ko
> >
> >roztyly# kldunload -v -i 6
> >Unloading if_gif.ko, id=6
> >
> >roztyly# kldunload -v -i 7
> >Unloading if_tun.ko, id=7
> >
> >roztyly# kldstat
> >Id Refs Address    Size     Name
> >1    8 0xc0400000 5bb9fc   kernel
> >2   16 0xc09bc000 63f04    acpi.ko
> >3    1 0xc1848000 23000    nfsserver.ko
> >4    1 0xc18b0000 1a000    linux.ko
> >
> >roztyly# ifconfig gif0 create
> >
> >roztyly# ifconfig gif0
> >gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280
> >
> >roztyly# ifconfig gif0 destroy
> >
> >roztyly# ifconfig gif0
> >ifconfig: interface gif0 does not exist
> >
> >roztyly# kldstat
> >Id Refs Address    Size     Name
> >1    9 0xc0400000 5bb9fc   kernel
> >2   16 0xc09bc000 63f04    acpi.ko
> >3    1 0xc1848000 23000    nfsserver.ko
> >4    1 0xc18b0000 1a000    linux.ko
> >7    1 0xc2910000 5000     if_gif.ko
> >
> >roztyly# ifconfig tun0 create
> >ifconfig: SIOCIFCREATE: Invalid argument
> >
> >roztyly# kldstat
> >Id Refs Address    Size     Name
> >1   10 0xc0400000 5bb9fc   kernel
> >2   16 0xc09bc000 63f04    acpi.ko
> >3    1 0xc1848000 23000    nfsserver.ko
> >4    1 0xc18b0000 1a000    linux.ko
> >7    1 0xc2910000 5000     if_gif.ko
> >8    1 0xc2926000 5000     if_tun.ko
> >
> >roztyly# ifconfig tun0 destroy
> >ifconfig: interface tun0 does not exist
> >
> >roztyly# kldstat
> >Id Refs Address    Size     Name
> >1   10 0xc0400000 5bb9fc   kernel
> >2   16 0xc09bc000 63f04    acpi.ko
> >3    1 0xc1848000 23000    nfsserver.ko
> >4    1 0xc18b0000 1a000    linux.ko
> >7    1 0xc2910000 5000     if_gif.ko
> >8    1 0xc2926000 5000     if_tun.ko
> >
> >roztyly#
> >
> >I use tspc2 (freenet6) port, and of course the starting/stopping scripts
> >deos not work as you and me expect. :(
> >
> >Dan
> >
> >Bye
> >_______________________________________________
> >freebsd-current_at_freebsd.org mailing list
> >http://lists.freebsd.org/mailman/listinfo/freebsd-current
> >To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
> >

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

Received on Tue Sep 06 2005 - 16:57:59 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:43 UTC