From owner-freebsd-net@FreeBSD.ORG Sat Jul 14 19:01:23 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4E22316A403 for ; Sat, 14 Jul 2007 19:01:23 +0000 (UTC) (envelope-from brett@lariat.net) Received: from lariat.net (lariat.net [66.119.58.2]) by mx1.freebsd.org (Postfix) with ESMTP id D62DB13C4B8 for ; Sat, 14 Jul 2007 19:01:22 +0000 (UTC) (envelope-from brett@lariat.net) Received: from anne-o1dpaayth1.lariat.org (IDENT:ppp1000.lariat.net@lariat.net [66.119.58.2]) by lariat.net (8.9.3/8.9.3) with ESMTP id NAA27366; Sat, 14 Jul 2007 13:01:13 -0600 (MDT) Message-Id: <200707141901.NAA27366@lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 14 Jul 2007 13:01:06 -0600 To: Brian Somers From: Brett Glass In-Reply-To: <20070714114132.6b395616@dev.lan.Awfulhak.org> References: <200707110014.SAA02181@lariat.net> <200707120114.TAA28481@lariat.net> <20070714114132.6b395616@dev.lan.Awfulhak.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: freebsd-net@freebsd.org, Mike Tancsa Subject: Re: Bug in userland PPP LQR? 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: Sat, 14 Jul 2007 19:01:23 -0000 At 12:41 PM 7/14/2007, Brian Somers wrote: >> disable lqr >> allow lqr > >accept lqr > >> enable echo >> echoperiod 12 > >set echoperiod 12 Yes, found and fixed both of these mistakes. >I'd also add "set log +lqm" to your configuration. Will try that. >I expect unacknowledged LQR packets to be resent >5 times (exactly the same packet), and the 6th >timeout to cause a line drop. That's what I thought too. But it seems as if a single dropped packet among plenty of successful ones can cause the session to drop. This is why I am wondering if the counter is properly reset or if one missed packet leads to a permanent loss of synchronization. >The spec says that the peer may ignore an LQR >request if it's under load, but that it must >respond to a duplicate LQR request. My suspicion >is that some implementations just ignore LQR >altogether under load. These implementations >should disable LQR if they can't implement it >properly. I'm mostly dealing with the Linux pppd or ports of it on the clients (since it seems to be the most popular open source implementation, regardless of quality). --Brett Glass