Re: PPP-layer Echo

From: Crist J. Clark (cristjc_at_comcast.net)
Date: 04/28/05

  • Next message: Barney Wolff: "Re: PPP-layer Echo" 
    Date: Wed, 27 Apr 2005 16:41:52 -0700
To: Neo-Vortex <root@Neo-Vortex.net>

    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
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
  • Next message: Barney Wolff: "Re: PPP-layer Echo"