From pjchilds@al.imforei.apana.org.au  Wed Jun 12 08:41:12 1996
Received: from al.imforei.apana.org.au (al.imforei.apana.org.au [202.12.89.41])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id IAA12907
          for <FreeBSD-gnats-submit@freebsd.org>; Wed, 12 Jun 1996 08:41:07 -0700 (PDT)
Received: (from pjchilds@localhost) by al.imforei.apana.org.au (8.7.5/8.7.3) id BAA05726; Thu, 13 Jun 1996 01:11:01 +0930 (CST)
Message-Id: <199606121541.BAA05726@al.imforei.apana.org.au>
Date: Thu, 13 Jun 1996 01:11:01 +0930 (CST)
From: Peter Childs <pjchilds@imforei.apana.org.au>
Reply-To: pjchilds@imforei.apana.org.au
To: FreeBSD-gnats-submit@freebsd.org
Subject: 10 tun limit
X-Send-Pr-Version: 3.2

>Number:         1316
>Category:       bin
>Synopsis:       10 tunnel device limit
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:
>Keywords:
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Jun 12 08:50:03 PDT 1996
>Closed-Date:    Mon Nov 4 06:47:14 PST 1996
>Last-Modified:  Mon Nov  4 06:48:20 PST 1996
>Originator:     Peter Childs
>Release:        FreeBSD 2.1-STABLE i386
>Organization:
Peter Childs  ---  http://www.imforei.apana.org.au/~pjchilds
   Active APANA SA Member  ---  Author PopWatch + Inf-HTML
  Email: pjchilds@imforei.apana.org.au   Fax: 61-8-82784742
>Environment:

 FreeBSD 2.1-STABLE using /usr/src/usr.sbin/ppp/os.c v1.3.4.2
 (the latest from the CVS web-tree util)

>Description:

 OpenTun() limits the maximum number of tunnel devices to 10
 due to a really interesting loop in the code...

>How-To-Repeat:

 vi /usr/src/usr.sbin/ppp/os.c
 269G

>Fix:

 Just use a plain for loop like is done in the -current code...

>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->feedback 
State-Changed-By: scrappy 
State-Changed-When: Tue Oct 22 20:44:06 PDT 1996 
State-Changed-Why:  

This problem is supposedly fixed in 2.2-CURRENT, and looking at 
the code, the function OpenTunnel() seems to have had the initial 
15 or so lines rewritten, but nothing that looks like a "structural" 
change. 

Would it be safe to apply the following to fix/close this PR, which is 
a diff of the changes (will make a context diff before I apply it) between 
2.2-CURRENT's usr.sbin/ppp/os.c and 2.1.5-RELEASE's: 

257a258,263 
>  
> #define MAX_TUN 256 
> /* MAX_TUN is set at an arbitrarily large value  * 
>  * as the loop aborts when it reaches the first  * 
>  * 'Device not configured' (ENXIO), or the third * 
>  * 'No such file or directory' (ENOENT) error.   */ 
263,264d268 
<   char *cp; 
<   char *suffix = "0123456789"; 
266c270,271 
<   char devname[12]; 
--- 
>   char devname[14];  /* sufficient room for "/dev/tun65535" */ 
>   unsigned unit, enoentcount=0; 
268,270c273,274 
<   strcpy(devname, "/dev/tun0"); 
<   for (cp = suffix; *cp; cp++) { 
<     devname[8] = *cp; 
--- 
>   for( unit=0; unit <= MAX_TUN ; unit++ ) { 
>     sprintf( devname, "/dev/tun%d", unit ); 
272,273c276,284 
<     if (tun_out >= 0) 
<       break; 
--- 
>     if( tun_out >= 0 ) 
>       break; 
>     if( errno == ENXIO ) 
>       unit=MAX_TUN+1; 
>     else if( errno == ENOENT ) { 
>       enoentcount++; 
>       if( enoentcount > 2 ) 
>               unit=MAX_TUN+1; 
>     } 
275,276c286 
<   *ptun = cp - suffix; 
<   if (*cp == '0') { 
--- 
>   if( unit > MAX_TUN ) { 
279a290 
>   *ptun = unit; 

State-Changed-From-To: feedback->closed 
State-Changed-By: scrappy 
State-Changed-When: Mon Nov 4 06:47:14 PST 1996 
State-Changed-Why:  

Fixed in 2.2-CURRENT...patched merged into 2.1.x tree 

>Unformatted:
