From owner-freebsd-net@FreeBSD.ORG Sun May 21 20:03:45 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7F2ED16A834 for ; Sun, 21 May 2006 20:03:45 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5EFAF43D5E for ; Sun, 21 May 2006 20:03:44 +0000 (GMT) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id k4LK3hCu090267; Sun, 21 May 2006 16:03:43 -0400 (EDT) (envelope-from mike@sentex.net) Received: from simian.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.3P/8.13.3) with ESMTP id k4LK3fYO011116 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 21 May 2006 16:03:41 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <6.2.3.4.0.20060521154616.11bd1d60@64.7.153.2> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Sun, 21 May 2006 16:03:39 -0400 To: Ian Smith From: Mike Tancsa In-Reply-To: References: <6.2.3.4.0.20060521104147.081af2d8@64.7.153.2> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by amavisd-new Cc: freebsd-net@freebsd.org, Brian Candler Subject: Re: improving transport over lossy links ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 May 2006 20:03:52 -0000 At 02:53 PM 21/05/2006, Ian Smith wrote: > > Its not so much data corruption of packets on the wire, but > > the modem dropping the connection, retraining and > > renegotiating. When the retrains and re negotiations happen, this > > can cause problems for the VPN as keep alives are missed, tx buffers > > can fill up etc. I have tried a number of modems, the current one > > being U.S. Robotics 56K FAX INT V5.22.70. and I am also trying an > > external Intel at the office > >Yes that's just the problem alright. Just to be clear, you're referring >here only to various calling-in modems, calling to these fixed terminal >server cards, of maybe Lucent origin, right? Hi, Correct. Its always dialing into a terminal server that is connected via PRIs. Usually Lucent PM3, sometimes Cisco 5800s depending on the location they dial from. > > The internal USR seems to correctly see the carrier drop and PPP > > hence sees it. However, the 2 external Intels I am experimenting > > with on the USB serial ports do not. I suspect thats part of the > > reason the DCD is not working. Perhaps incorrect init string or > > something with the USB-Serial. Note, I only have the internal USRs > > deployed in the field right now > >Don't know about USB modems. Do USR still use their own chipsets, or >what? In any case, they're probably highly tunable and well documented. Actually, they are just regular external modems connected to USB to serial adaptors (using the uftdi driver) >Not V.90 full tilt, anyway. If 45333 is sort of usual for this one, >then I'd probably try telling it to connect no higher than maybe 41333 >or 40000; often about 10-15% or so less than 'normal' can make all the >difference. If you can afford the bandwidth, go for slow and solid .. Yes, for sure I will try and lower the speeds a bit, but ultimately I want to deal with situations where the carrier drops and the modem has to redial. The client is willing to put in an extra phone line if it would make the link more reliable. Typically these sites are too remote for other types of transport. I think if I can get mp working with reliable dcd I think that should do it. ---Mike