Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 28 Apr 2005 08:38:01 +1000 (EST)
From:      Neo-Vortex <root@Neo-Vortex.net>
To:        "Crist J. Clark" <cjc@freebsd.org>
Cc:        freebsd-net@freebsd.org
Subject:   Re: PPP-layer Echo
Message-ID:  <20050428083604.O10942@Neo-Vortex.net>
In-Reply-To: <20050427172304.GA26712@goku.cjclark.org>
References:  <20050427172304.GA26712@goku.cjclark.org>

next in thread | previous in thread | raw e-mail | index | archive | help


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.



~Neo-Vortex



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050428083604.O10942>