From scottl@mindspring.com  Sun Mar 19 15:14:30 2000
Return-Path: <scottl@mindspring.com>
Received: from granger.mail.mindspring.net (granger.mail.mindspring.net [207.69.200.148])
	by hub.freebsd.org (Postfix) with ESMTP id 2542437B6D1
	for <FreeBSD-gnats-submit@freebsd.org>; Sun, 19 Mar 2000 15:14:28 -0800 (PST)
	(envelope-from scottl@mindspring.com)
Received: from mindspring.com (user-33qtpit.dialup.mindspring.com [199.174.230.93])
	by granger.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id SAA05243
	for <FreeBSD-gnats-submit@freebsd.org>; Sun, 19 Mar 2000 18:03:52 -0500 (EST)
Received: (from scottl@localhost)
	by  mindspring.com (8.9.3/8.9.3) id OAA00442;
	Sun, 19 Mar 2000 14:23:28 -0700 (MST)
	(envelope-from scottl)
Message-Id: <200003192123.OAA00442@ mindspring.com>
Date: Sun, 19 Mar 2000 14:23:28 -0700 (MST)
From: scott_long@btc.adaptec.com
Sender: scottl@mindspring.com
Reply-To: scott_long@btc.adaptec.com
To: FreeBSD-gnats-submit@freebsd.org
Subject: Two issues with the tun device
X-Send-Pr-Version: 3.2

>Number:         17494
>Category:       kern
>Synopsis:       Two problems with the tun device
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sun Mar 19 15:20:01 PST 2000
>Closed-Date:    Sat Jul 21 17:50:11 PDT 2001
>Last-Modified:  Sat Jul 21 17:50:30 PDT 2001
>Originator:     Scott Long
>Release:        FreeBSD 5.0-CURRENT i386
>Organization:
>Environment:

FreeBSD 5.0-CURRENT as of 3/18/00

>Description:
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.


>How-To-Repeat:


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


>Release-Note:
>Audit-Trail:

From: Brian Somers <brian@Awfulhak.org>
To: scott_long@btc.adaptec.com
Cc: FreeBSD-gnats-submit@FreeBSD.ORG, brian@hak.lan.Awfulhak.org
Subject: Re: kern/17494: Two issues with the tun device 
Date: Mon, 20 Mar 2000 00:54:45 +0000

 > 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 !
 
 
 
State-Changed-From-To: open->closed 
State-Changed-By: mike 
State-Changed-When: Sat Jul 21 17:50:11 PDT 2001 
State-Changed-Why:  

Timeout; no response from originator. 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=17494 
>Unformatted:
