From owner-freebsd-net@FreeBSD.ORG Thu Apr 28 00:35:42 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 7E7AF16A4CE for ; Thu, 28 Apr 2005 00:35:42 +0000 (GMT) Received: from pit.databus.com (p70-227.acedsl.com [66.114.70.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id F035443D5F for ; Thu, 28 Apr 2005 00:35:41 +0000 (GMT) (envelope-from barney@databus.com) Received: from pit.databus.com (localhost [127.0.0.1]) by pit.databus.com (8.13.3/8.13.3) with ESMTP id j3S0ZXuw078092; Wed, 27 Apr 2005 20:35:33 -0400 (EDT) (envelope-from barney@pit.databus.com) Received: (from barney@localhost) by pit.databus.com (8.13.3/8.13.3/Submit) id j3S0ZXvM078091; Wed, 27 Apr 2005 20:35:33 -0400 (EDT) (envelope-from barney) Date: Wed, 27 Apr 2005 20:35:33 -0400 From: Barney Wolff To: cjclark@alum.mit.edu Message-ID: <20050428003533.GA71718@pit.databus.com> References: <20050427172304.GA26712@goku.cjclark.org> <20050428083604.O10942@Neo-Vortex.net> <20050427234152.GB27013@goku.cjclark.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050427234152.GB27013@goku.cjclark.org> User-Agent: Mutt/1.5.9i X-Scanned-By: MIMEDefang 2.51 on 66.114.72.185 cc: freebsd-net@freebsd.org Subject: Re: PPP-layer Echo X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2005 00:35:42 -0000 On Wed, Apr 27, 2005 at 04:41:52PM -0700, Crist J. Clark wrote: > > 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. It is wrong. Is the other end OS/2 or something derived from it? I recall, from a decade ago, that this was about what some version of OS/2 did wrong. -- Barney Wolff http://www.databus.com/bwresume.pdf I never met a computer I didn't like.