From nobody@FreeBSD.org  Thu Apr 26 13:50:19 2007
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id 8A69A16A400
	for <freebsd-gnats-submit@FreeBSD.org>; Thu, 26 Apr 2007 13:50:19 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (www.freebsd.org [69.147.83.33])
	by mx1.freebsd.org (Postfix) with ESMTP id 6102D13C448
	for <freebsd-gnats-submit@FreeBSD.org>; Thu, 26 Apr 2007 13:50:19 +0000 (UTC)
	(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 l3QDoJNC016536
	for <freebsd-gnats-submit@FreeBSD.org>; Thu, 26 Apr 2007 13:50:19 GMT
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.13.1/8.13.1/Submit) id l3QDjH1I007013;
	Thu, 26 Apr 2007 13:45:17 GMT
	(envelope-from nobody)
Message-Id: <200704261345.l3QDjH1I007013@www.freebsd.org>
Date: Thu, 26 Apr 2007 13:45:17 GMT
From: bob frazier<bobf@mrp3.com>
To: freebsd-gnats-submit@FreeBSD.org
Subject: uplink DSL w/pppoe+NAT 'out of buffer space' kills connection
X-Send-Pr-Version: www-3.0

>Number:         112160
>Category:       kern
>Synopsis:       [pppd] uplink DSL w/pppoe+NAT 'out of buffer space' kills connection
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Apr 26 14:00:12 GMT 2007
>Closed-Date:    
>Last-Modified:  Thu Apr 26 22:46:56 GMT 2007
>Originator:     bob frazier
>Release:        5.5-STABLE
>Organization:
software engineer
>Environment:
FreeBSD BSDServer.SFT.local 5.5-STABLE FreeBSD 5.5-STABLE #2: Sat Mar 10 01:59:08 PST 2007     root@BSDServer.SFT.local:/usr/obj/usr/src/sys/MY_KERNEL  i386
>Description:
I have done this twice and had the same thing happen both times.
Although it may be due in part to maintenance on the connection by the
ISP the first time, the second time it was most likely NOT from ISP maintenance.

After downloading a popular torrent I left the downloader on all night
to allow others to benefit from my uplink bandwidth.  The downloader
was running on a linux machine connected to the private LAN, with NAT
forwarding via the ppp client running in user mode.  Normally this
connection stays 'live' for weeks at a time without incident.

Unfortunately the high upload bandwidth seems to cause pppoe to 'choke'
and after an 'out of buffer space' condition shuts down ALL networking
I have to close both ppp and named and manually 'ifconfig tun0 down'
(and make sure no IP address assigned to tun0, etc.) AND recycle the
DSL modem to make everything work again.  PPP logs suggest that the DSL
modem was still working, but for some reason there was no packet flow.
I believe the loss of packet flow was due to (specifically) the 'out
of buffer space' condition, which I've also observed while bandwidth
testing wifi connections via iperf.  If you modify iperf to NOT shut
down on 'out of buffer space', but rather periodically retry sending
data, it literally shuts down ALL OTHER NETWORK ACTIVITY (regardless
of whether or not it runs as root).  It seems that system buffers
(rather than per-user buffers) are being filled up.


>How-To-Repeat:
a) perform 'bit-torrent' uplink for hours on end via a PPPOE connection
   over DSL
a.1) alternately use iperf to perform the same task, uploading via UDP
     with a large window size and bandwidth set to a value far greater
     than the connection can support.

b) ensure that the bandwidth "maxes out" as much as possible

c) observe loss of connectivity, and inability to auto-re-dial the
   PPPOE connection.


alternate (related) problem

using a modified version of iperf (ask me for a patch if you want a
copy), stress any 'bandwidth restricted' network connection by flooding
it with UDP (uplink) traffic at a bandwidth higher than the device is
capable of handling.  Wait for 'out of buffer space' and note the effect
it has on ALL network traffic if this condition is 'maintained' by
iperf's flood attempts.

>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted:
