Bug 17494

Summary: Two problems with the tun device
Product: Base System Reporter: scott_long <scott_long>
Component: kernAssignee: freebsd-bugs (Nobody) <bugs>
Status: Closed FIXED    
Severity: Affects Only Me    
Priority: Normal    
Version: 5.0-CURRENT   
Hardware: Any   
OS: Any   

Description scott_long 2000-03-19 23:20:01 UTC 
In the course of writing a simple GUI network monitor/dialup front-end, I have
come across a couple of quirks in the tunnel driver that don't seem to exist 
in other network drivers (ppp, sl, lo, ether).

1.  the ifnet structure for the tun device is not created at attach time like
it is for other network drivers.  Instead, it is created when the device is
opened, if it hasn't already been created in a previous open.  This behaviour
causes my program to not see the tun device unless a program like ppp(8) is
run first, which defeats one of the goals of this program: to control dialup
networking.  Comparing code in if_[tun|ppp|sl|lo].c shows that all but tun
create the ifnet structure from within their respective attach routine.  But
on the other hand, if_tun.c uses make_dev while the others do not.  Making
if_tun.c resemble the others is a trivial task, but I am not sure what would
be lost by eliminating make_dev (which requires a dev_t argument that attach
cannot supply, if I understand things correctly).

2.  when the tun interface is put into promiscuous mode (via tcpdump)
IFF_PROMISC is set as expected.  When tcpdump is exited and the bpf interface
is closed, the IFF_PROMISC flag is not unset.  On other interfaces this works
correctly.  I have not been able to figure this one out yet.

Fix: 

As stated above, creating the ifnet struct in the attach vs open routine is
fairly trivial, but at the cost of make_dev.  I can supply a patch if
requested.
Comment 1 Brian Somers 2000-03-20 00:54:45 UTC 
> 1.  the ifnet structure for the tun device is not created at attach time like
> it is for other network drivers.  Instead, it is created when the device is
> opened, if it hasn't already been created in a previous open.  This behaviour
> causes my program to not see the tun device unless a program like ppp(8) is
> run first, which defeats one of the goals of this program: to control dialup
> networking.  Comparing code in if_[tun|ppp|sl|lo].c shows that all but tun
> create the ifnet structure from within their respective attach routine.  But
> on the other hand, if_tun.c uses make_dev while the others do not.  Making
> if_tun.c resemble the others is a trivial task, but I am not sure what would
> be lost by eliminating make_dev (which requires a dev_t argument that attach
> cannot supply, if I understand things correctly).

Interfaces are moving towards being a lot more dynamic than they have 
been in the past.  This new behaviour of the tun device is IMHO the 
way forward rather than a problem that has to be fixed.

The way things currently are, you don't even need a tun device 
specified in your kernel.  The module is as functional and will 
create new interfaces and softcs as required.  In the future, I 
would think it's likely that the last close() will remove the 
interface.

Why does you program require the interfaces existence up front ?  
Surely this is where the problem lies ?
-- 
Brian <brian@Awfulhak.org>                        <brian@[uk.]FreeBSD.org>
      <http://www.Awfulhak.org>                   <brian@[uk.]OpenBSD.org>
Don't _EVER_ lose your sense of humour !
Comment 2 Mike Barcroft freebsd_committer freebsd_triage 2001-07-22 01:50:11 UTC 
State Changed
From-To: open->closed


Timeout; no response from originator.