From nobody@FreeBSD.org Thu Apr 26 13:50:19 2007 Return-Path: Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8A69A16A400 for ; 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 ; 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 ; 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 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: