Subject: Re: Tap(4) interface in NetBSD?
To: Greg Troxel <firstname.lastname@example.org>
From: Andrew Brown <email@example.com>
Date: 04/28/2003 09:41:09
>I used this to build an emulator that could be glued in for real
>traffic. IMHO the big differentiator of the new interface is the
>ability to control far more about how the interface behaves than tun
>currently lets you do. But having implemented this, I don't see any
>obvious reason tun could not be extended instead - it could simply
>default to tun-like behavior if none of the special ioctls are called.
>The tricky part is having interfaces be able to change type. But,
>since tun is a create/destroy interface already, one can augment the
>create call to pass in the tunnel/ethernet flag and the mac address,
>and not allow type changing once created. It would be good for this
>to be extensible, since one might want to add the ability to say
>e.g. 'this is an 802.11 interface'.
since "extending" the creat/destroy interface might be a little
tricky, how about asserting that all programs must go through three
set required options, specify link layer, etc
set interface to "up" and begin operating
and then merely require that the interface, once up, is considered
"immutable", and must be closed before any of the settings/options can
be changed. that way the users of the original tun interface would
get what they expect, and new userspace tunnel types can be slid in
|-----< "CODE WARRIOR" >-----|
firstname.lastname@example.org * "ah! i see you have the internet
email@example.com (Andrew Brown) that goes *ping*!"
firstname.lastname@example.org * "information is power -- share the wealth."