From owner-freebsd-net@FreeBSD.ORG Wed Apr 27 23:42:08 2005 Return-Path: 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 2F9CD16A4CE for ; Wed, 27 Apr 2005 23:42:08 +0000 (GMT) Received: from sccrmhc14.comcast.net (sccrmhc14.comcast.net [204.127.202.59]) by mx1.FreeBSD.org (Postfix) with ESMTP id 93E9E43D2D for ; Wed, 27 Apr 2005 23:42:02 +0000 (GMT) (envelope-from cristjc@comcast.net) Received: from goku.cjclark.org (c-24-6-187-112.hsd1.ca.comcast.net[24.6.187.112]) by comcast.net (sccrmhc14) with ESMTP id <20050427234201014009utnqe>; Wed, 27 Apr 2005 23:42:01 +0000 Received: from goku.cjclark.org (localhost. [127.0.0.1]) by goku.cjclark.org (8.13.3/8.12.8) with ESMTP id j3RNfuhS027913; Wed, 27 Apr 2005 16:41:56 -0700 (PDT) (envelope-from cristjc@comcast.net) Received: (from cjc@localhost) by goku.cjclark.org (8.13.3/8.13.1/Submit) id j3RNfqti027912; Wed, 27 Apr 2005 16:41:52 -0700 (PDT) (envelope-from cristjc@comcast.net) X-Authentication-Warning: goku.cjclark.org: cjc set sender to cristjc@comcast.net using -f Date: Wed, 27 Apr 2005 16:41:52 -0700 From: "Crist J. Clark" To: Neo-Vortex Message-ID: <20050427234152.GB27013@goku.cjclark.org> References: <20050427172304.GA26712@goku.cjclark.org> <20050428083604.O10942@Neo-Vortex.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050428083604.O10942@Neo-Vortex.net> User-Agent: Mutt/1.4.2.1i X-URL: http://people.freebsd.org/~cjc/ cc: freebsd-net@freebsd.org Subject: Re: PPP-layer Echo X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: cjclark@alum.mit.edu List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2005 23:42:08 -0000 On Thu, Apr 28, 2005 at 08:38:01AM +1000, Neo-Vortex wrote: > > > On Wed, 27 Apr 2005, Crist J. Clark wrote: > > > All I want to do is send an echo-request and listen for the > > echo-reply at the PPP layer. Note that I am talking about > > pings _at the link layer,_ not IP layer pings. A quick look > > at the ppp(8) manpage didn't seem to indicate any tools for > > sending or receiving PPP-layer echoes. If ppp(8) doesn't have > > the ability, does anyone have any other _simple_ suggestions > > for doing this (e.g. dunno if it's worth writing a netgrap(4) > > node for this unless its really simple)? > > By link layer ping, do you mean lqr stuff? > > lqr > Default: Disabled and Accepted. This option decides if Link > Quality Requests will be sent or accepted. LQR is a protocol > that allows ppp to determine that the link is down without rely- > ing on the modems carrier detect. When LQR is enabled, ppp sends > the QUALPROTO option (see ``set lqrperiod'' below) as part of the > LCP request. If the peer agrees, both sides will exchange LQR > packets at the agreed frequency, allowing detailed link quality > monitoring by enabling LQM logging. If the peer doesn't agree, > ppp will send ECHO LQR requests instead. These packets pass no > information of interest, but they MUST be replied to by the peer. > > Whether using LQR or ECHO LQR, ppp will abruptly drop the connec- > tion if 5 unacknowledged packets have been sent rather than send- > ing a 6th. A message is logged at the PHASE level, and any > appropriate ``reconnect'' values are honoured as if the peer were > responsible for dropping the connection. If the other end of the PPP refuses the LQR, our end will fall back to PPP ECHOs. In the case I am investigating, this is the case, so I do get the ECHOs. Yay me. However, I'm seeing some weirdness, and I wonder if any PPP gurus can comment. My end sends a ping (a HDLC dump), ff 03 c0 21 09 01 00 10 6d a8 39 0d 59 4e 4f 54 00 00 00 01 52 b6 ^^^^^ ^^^^^ ^^ ^^ ^^^^^ ^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^ PPP LCP Id Len. Magic No. Data FCS Echo- Request And receives this, ff 03 c0 21 0a 01 00 14 e8 67 ea ac 6d a8 39 0d 59 4e 4f 54 00 00 00 01 29 35 ^^^^^ ^^^^^ ^^ ^^ ^^^^^ ^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^ PPP LCP Id Len. Magic No. Data FCS Echo- Reply Which looks a bit strange to me. My end is rejecting those echoes as bogus because the data we send does not match the data we get back. What looks like is happening is that the other end of the PPP is taking the Magic Number field from the echo request and copying it into the data field. That also explains why the response is 4 bytes longer than the request. I'm no PPP expert, but this is looking pretty fishy. Is the other end totally broken? However, RFC1661 isn't totally explicit about how the data field needs to be handled, Data The Data field is zero or more octets, and contains uninterpreted data for use by the sender. The data may consist of any binary value. The end of the field is indicated by the Length. But it seems wrong to modify the data field. -- Crist J. Clark | cjclark@alum.mit.edu