From nobody@FreeBSD.org  Sat Sep 17 16:58:59 2005
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 277F916A41F
	for <freebsd-gnats-submit@FreeBSD.org>; Sat, 17 Sep 2005 16:58:59 +0000 (GMT)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (www.freebsd.org [216.136.204.117])
	by mx1.FreeBSD.org (Postfix) with ESMTP id CADE043D45
	for <freebsd-gnats-submit@FreeBSD.org>; Sat, 17 Sep 2005 16:58:58 +0000 (GMT)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.13.1/8.13.1) with ESMTP id j8HGwwQK060800
	for <freebsd-gnats-submit@FreeBSD.org>; Sat, 17 Sep 2005 16:58:58 GMT
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.13.1/8.13.1/Submit) id j8HGwwnJ060799;
	Sat, 17 Sep 2005 16:58:58 GMT
	(envelope-from nobody)
Message-Id: <200509171658.j8HGwwnJ060799@www.freebsd.org>
Date: Sat, 17 Sep 2005 16:58:58 GMT
From: Bob Frazier <bobf@mrp3.com>
To: freebsd-gnats-submit@FreeBSD.org
Subject: 'out of buffer space' after many PPPoE re-dial attempts, connectivity lost
X-Send-Pr-Version: www-2.3

>Number:         86261
>Category:       kern
>Synopsis:       'out of buffer space' after many PPPoE re-dial attempts, connectivity lost
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    brian
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sat Sep 17 17:00:24 GMT 2005
>Closed-Date:    Sat Jul 18 21:39:31 UTC 2009
>Last-Modified:  Sat Jul 18 21:39:31 UTC 2009
>Originator:     Bob Frazier
>Release:        5.4-STABLE (7/21/2005)
>Organization:
SFT INc.
>Environment:
FreeBSD BSDServer.SFT.local 5.4-STABLE FreeBSD 5.4-STABLE #0: Sat Jul 23 04:33:01 PDT 2005 root@BSDServer.SFT.local:/usr/obj/usr/src/sys/MY_KERNEL  i386

>Description:
      At various times my DSL service provider loses connectivity, and ppp must re-dial the PPPoE connection to maintain it.  After the system has been running for quite some time.  uptime would have likely been since the last kernel build (around 7/22/2005).  Since that time period, countless re-dials by ppp have been performed.

At approximately midnight, I had a series of redials take place, which ultimately resulted in the following errors in /var/log/messages, and a complete loss of internet connectivity.

Sep 16 23:59:13 BSDServer routed[289]: ignore RTM_CHANGE without mask
Sep 16 23:59:13 BSDServer routed[289]: ignore RTM_CHANGE without mask
(these two errors happen all of the time whenever the ppp connection is established)
Sep 16 23:59:25 BSDServer ppp[230]: tun0: Warning: deflink: Reducing configured MRU from 1500 to 1492
(this is also normal)
Sep 17 00:01:00 BSDServer routed[289]: Send sendto(tun0, 216.175.112.1.520): No buffer space available
Sep 17 00:01:30 BSDServer routed[289]: Send sendto(tun0, 216.175.112.1.520): No buffer space available
Sep 17 00:03:30 BSDServer last message repeated 4 times

The previous sequence then repeated itself every few minutes as ppp attempted to re-dial the PPPoE connection indefinitely.  I am using a Zyxel DSL modem through earthlink.

>How-To-Repeat:
I have only seen this problem once before, and it was caused by the same thing - ISP drops connection a sufficient number of times until ppp has re-dialed enough to cause the 'no buffer space available' error.  An extremely unreliable DSL connection (constantly dropping) with a lot of internet traffic and connections to services like IRC that stay up for days at a time over this connection, gigabytes of data transferred, services like http and ftp and ssh providing content, etc. connected to the internet for several weeks using PPPoE over a DSL connection where 'ppp' is providing the PPPoE login.  At some point a resource limit is exceeded, and then all internet connectivity is lost.
>Fix:
      rebooting the system restored connectivity in both cases.  This problem never occurred prior to FreeBSD 5.3-RELEASE, possibly not even until FreeBSD 5.4-RELEASE.

>Release-Note:
>Audit-Trail:

From: Gleb Smirnoff <glebius@FreeBSD.org>
To: Bob Frazier <bobf@mrp3.com>
Cc: freebsd-gnats-submit@FreeBSD.org
Subject: Re: kern/86261: 'out of buffer space' after many PPPoE re-dial attempts, connectivity lost
Date: Wed, 21 Sep 2005 17:45:24 +0400

   Bob,
 
   next time this happends, please check the following things:
 
 1) Does restart ppp(8) helps? To check this you will need to:
 
    /etc/rc.d/ppp-user stop
    [check that no ppp process is present]
    /etc/rc.d/ppp-user start
 
 If no success on 1), follow to 2):
 
 2) Does restart of ppp(8) + renewal of tun(4) interface help?
 
    /etc/rc.d/ppp-user stop
    [check that no ppp process is present]
    ifconfig tun0 destroy
    [check that tun0 interfaces disappeared]
    /etc/rc.d/ppp-user start
 
 2) Does restart of ppp(8) + renewal of tun(4) + renewal of netgraph
    PPPoE node helps?
 
    /etc/rc.d/ppp-user stop
    [check that no ppp process is present]
    ifconfig tun0 destroy
    [check that tun0 interfaces disappeared]
    ngctl shutdown fxp0:orphans   [assuming you run PPPoE on fxp0]
    [check that no PPPoE nodes remained, 'ngctl types | grep pppoe' must
     display 0]
 
 -- 
 Totus tuus, Glebius.
 GLEBIUS-RIPN GLEB-RIPE

From: Gleb Smirnoff <glebius@FreeBSD.org>
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/86261: 'out of buffer space' after many PPPoE re-dial attempts, connectivity lost
Date: Wed, 5 Oct 2005 11:32:46 +0400

   Attach this to Audit-Trail.
 
 ----- Forwarded message from Bob Frazier <bobf@mrp3.com> -----
 
 >   next time this happends, please check the following things:
 
 It happened again today
 
 > 1) Does restart ppp(8) helps? To check this you will need to:
 >
 >    /etc/rc.d/ppp-user stop
 >    [check that no ppp process is present]
 
 in my case it was still running.  I did a 'kill ###' on it, which ended it.
 
 >    /etc/rc.d/ppp-user start
 
 This made the problem go away!  Only /dev/tun0 was present, so the tun
 device was properly deleted when I killed the process, FYI.
 
 So it looks like it's client-side ppp doing it.
 
 ----- End forwarded message -----
Responsible-Changed-From-To: freebsd-bugs->brian 
Responsible-Changed-By: glebius 
Responsible-Changed-When: Wed Oct 5 10:19:58 GMT 2005 
Responsible-Changed-Why:  
Looks like related to ppp(8). Let Brian look at it. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=86261 
State-Changed-From-To: open->feedback 
State-Changed-By: brian 
State-Changed-When: Sun Jun 14 07:10:03 UTC 2009 
State-Changed-Why:  
Sorry I'm a little late to respond here... 

I'd be interested (if the originator still has such a setup) to 
know if routed is the only thing with a problem or if ppp ends up 
in a state where it's never able to re-establish the connection. 
If ppp is stuck, can the originator try something like "set log 
+phase lcp ipcp physical" and send the resulting log? 

I'm guessing that routed is sending traffic to tun0, but as ppp 
isn't connected, it won't read the data... after some time the 
interface queue just gets too big. 

If ppp is getting stuck, maybe I can reproduce the problem by having 
some other process repeatedly write something to tun0.  If such 
traffic is hurting ppp's abililty to connect, then it can probably 
be taught to detect this and purge the offending data. 

Thanks. 


http://www.freebsd.org/cgi/query-pr.cgi?pr=86261 
State-Changed-From-To: feedback->closed 
State-Changed-By: brian 
State-Changed-When: Sat Jul 18 21:37:26 UTC 2009 
State-Changed-Why:  
No response from the submitter in over three weeks.  I conceed that I didn't 
originally respond in over three years, but I can't help without additional 
details (as per the feedback request). 

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