Date: Wed, 27 Apr 2005 16:41:52 -0700 From: "Crist J. Clark" <cristjc@comcast.net> To: Neo-Vortex <root@Neo-Vortex.net> Cc: freebsd-net@freebsd.org Subject: Re: PPP-layer Echo Message-ID: <20050427234152.GB27013@goku.cjclark.org> In-Reply-To: <20050428083604.O10942@Neo-Vortex.net> References: <20050427172304.GA26712@goku.cjclark.org> <20050428083604.O10942@Neo-Vortex.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050427234152.GB27013>