misc/112160: uplink DSL w/pppoe+NAT 'out of buffer space' kills
bobf at mrp3.com
Thu Apr 26 14:00:13 UTC 2007
>Synopsis: uplink DSL w/pppoe+NAT 'out of buffer space' kills connection
>Arrival-Date: Thu Apr 26 14:00:12 GMT 2007
>Originator: bob frazier
FreeBSD BSDServer.SFT.local 5.5-STABLE FreeBSD 5.5-STABLE #2: Sat Mar 10 01:59:08 PST 2007 root at BSDServer.SFT.local:/usr/obj/usr/src/sys/MY_KERNEL i386
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 bu
ffer 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.
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.
More information about the freebsd-bugs