From nobody@FreeBSD.org  Mon Apr 15 12:12:12 2002
Return-Path: <nobody@FreeBSD.org>
Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21])
	by hub.freebsd.org (Postfix) with ESMTP id 69A2C37B400
	for <freebsd-gnats-submit@FreeBSD.org>; Mon, 15 Apr 2002 12:12:12 -0700 (PDT)
Received: (from nobody@localhost)
	by freefall.freebsd.org (8.11.6/8.11.6) id g3FJCCJ39250;
	Mon, 15 Apr 2002 12:12:12 -0700 (PDT)
	(envelope-from nobody)
Message-Id: <200204151912.g3FJCCJ39250@freefall.freebsd.org>
Date: Mon, 15 Apr 2002 12:12:12 -0700 (PDT)
From: Brian Curnow <bc@sonnet.com>
To: freebsd-gnats-submit@FreeBSD.org
Subject: Kernel refuses to assign unused IP to tun via ppp after some time
X-Send-Pr-Version: www-1.0

>Number:         37109
>Category:       kern
>Synopsis:       [ppp]: [tun]: Kernel refuses to assign unused IP to tun via ppp after some time
>Confidential:   no
>Severity:       serious
>Priority:       low
>Responsible:    remko
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Apr 15 12:20:00 PDT 2002
>Closed-Date:    Sun Dec 31 21:37:41 GMT 2006
>Last-Modified:  Sun Dec 31 21:37:41 GMT 2006
>Originator:     Brian Curnow
>Release:        4.5-STABLE
>Organization:
>Environment:
4.5-STABLE FreeBSD 4.5-STABLE #0: Sat Apr  6 14:09:35 PST 2002
>Description:
Using pptpd, ppp.  Appears to be a kernel bug which believes that
certain IPs, after having previously been used on interface, are still
in use and refuses to allow ppp to assign them.  Given enough time,
this will cause even large ranges of IP to be unusable until reboot.

I believe this is a kernel bug because my look at the ppp code seemed
to be that ppp does not keep any state on IP or interface use, and
tries range until the kernel accepts one that is offered.

System is SMP.

ppp.log errors:
Error: iface_inAdd: ioctl(SIOCAIFADDR): 10.0.0.3: File exists 
Error: ipcp_InterfaceUp: unable to set ip address 
Warning: iface_addr_Zap: ioctl(SIOCDIFADDR, 10.0.0.3): Can't assign requested address

IN this case, 10.0.0.3 is the local IP side, and the actual IP that can't be
assigned is the peer IP of 10.0.0.61.  In this case, changing the peer IP
in /etc/ppp/ppp.secret allowed the connection to proceed.  Over time,
all IPs will become unusable.
>How-To-Repeat:
running ppp via tun interface to pptpd seems to cause problem over time.
 Perhaps a race condition?
>Fix:
Unknown.  Cure by reboot.
>Release-Note:
>Audit-Trail:

From: Peter Pentchev <roam@ringlet.net>
To: Brian Curnow <bc@sonnet.com>
Cc: freebsd-gnats-submit@FreeBSD.org
Subject: Re: kern/37109: Kernel refuses to assign unused IP to tun via ppp after some time
Date: Tue, 16 Apr 2002 13:29:09 +0300

 On Mon, Apr 15, 2002 at 12:12:12PM -0700, Brian Curnow wrote:
 > 
 > >Number:         37109
 > >Category:       kern
 > >Synopsis:       Kernel refuses to assign unused IP to tun via ppp after some time
 > >Originator:     Brian Curnow
 > Using pptpd, ppp.  Appears to be a kernel bug which believes that
 > certain IPs, after having previously been used on interface, are still
 > in use and refuses to allow ppp to assign them.  Given enough time,
 > this will cause even large ranges of IP to be unusable until reboot.
 > 
 > I believe this is a kernel bug because my look at the ppp code seemed
 > to be that ppp does not keep any state on IP or interface use, and
 > tries range until the kernel accepts one that is offered.
 > 
 > System is SMP.
 > 
 > ppp.log errors:
 > Error: iface_inAdd: ioctl(SIOCAIFADDR): 10.0.0.3: File exists 
 > Error: ipcp_InterfaceUp: unable to set ip address 
 > Warning: iface_addr_Zap: ioctl(SIOCDIFADDR, 10.0.0.3): Can't assign requested address
 > 
 > IN this case, 10.0.0.3 is the local IP side, and the actual IP that can't be
 > assigned is the peer IP of 10.0.0.61.  In this case, changing the peer IP
 > in /etc/ppp/ppp.secret allowed the connection to proceed.  Over time,
 > all IPs will become unusable.
 > >How-To-Repeat:
 > running ppp via tun interface to pptpd seems to cause problem over time.
 >  Perhaps a race condition?
 > >Fix:
 > Unknown.  Cure by reboot.
 
 FWIW, I had this happen recently on a server which has five incoming
 PPP-over-TCP connections up most of the time.  After some flakiness on
 the part of the network connection, one of those interfaces started
 whining in the exact same way.
 
 A buildworld/buildkernel/installkernel/installworld/reboot cured it;
 it has not happened in the last six days.  I am not sure that it is
 gone for good; if it should happen again, I will be happy to provide
 any diagnostics that people request beforehand; unfortunately, it is
 very likely that the box will have to be rebooted to cure the problem
 again very soon after this happens, or some customers will be slightly
 irritated :)
 
 G'luck,
 Peter
 
 -- 
 Peter Pentchev	roam@ringlet.net	roam@FreeBSD.org
 PGP key:	http://people.FreeBSD.org/~roam/roam.key.asc
 Key fingerprint	FDBA FD79 C26F 3C51 C95E  DF9E ED18 B68D 1619 4553
 .siht ekil ti gnidaer eb d'uoy ,werbeH ni erew ecnetnes siht fI
State-Changed-From-To: open->feedback 
State-Changed-By: remko 
State-Changed-When: Sun Dec 31 11:11:47 UTC 2006 
State-Changed-Why:  
Hello, can you confirm that as with Peter this problem got 
solved? If not; is this still accurate on FreeBSD 6.x? 


Responsible-Changed-From-To: freebsd-bugs->remko 
Responsible-Changed-By: remko 
Responsible-Changed-When: Sun Dec 31 11:11:47 UTC 2006 
Responsible-Changed-Why:  
grab the PR 

http://www.freebsd.org/cgi/query-pr.cgi?pr=37109 
State-Changed-From-To: feedback->closed 
State-Changed-By: remko 
State-Changed-When: Sun Dec 31 21:35:39 UTC 2006 
State-Changed-Why:  
The submitter (thanks for the feedback on this short notice!) 
mentions that he cannot currently reproduce this issue, 
notice however that the submission was done on a SMP system 
and the current info is based on a non-SMP system. If you 
however have feedback that requires this PR to be re-evaluated 
please contact me and we will look together how we can resolve 
this issue. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=37109 
>Unformatted:
