[2158] in linux-net channel archive
Re: LCP echo problems (again)
daemon@ATHENA.MIT.EDU (Al Longyear)
Tue Mar 19 21:44:07 1996
To: linuxsys@ssg.com
Date: Tue, 19 Mar 1996 18:09:38 -0800 (PST)
From: "Al Longyear" <longyear@netcom.com>
Cc: linux-net@vger.rutgers.edu
In-Reply-To: <199603191332.AA04589@ssg.com> from "linuxsys@ssg.com" at Mar 19, 96 01:32:44 pm
linuxsys@ssg.com wrote:
> I'm still having problems maintaining a PPP link. The following
> command should have generated a number of echo exchanges:
> pppd connect "chat -v -f /etc/ppp/dial-dsc-fst" /dev/cua1 38400 -detach debug lcp-echo-failure 16 lcp-echo-interval 15 &
>
> Instead, here's what happened:
> Mar 19 13:21:18 wxsat pppd[4571]: local IP address 206.228.127.31
> Mar 19 13:21:18 wxsat pppd[4571]: remote IP address 206.228.127.2
There have been reports of people attempting to use the Linux PPP process
with broken clients on the other end of the telephone line.
The most common problem is that they totally freq out when they see a unknown
frame. They will usually follow the RFC in that they will send a protocol
reject, but they fail to understand that the CCP frame is an independent
protocol and they try to take down the link when they see the CCP frame.
There are a few solutions:
1. Complain to the peer system and get them to fix their bad code on their
system so that it does not become confused with CCP. If this is a commercial
provider then the chances are that they are using a terminal server with
old firmware. (That, by far, is the most common of the cases.)
If they are using a commercial program, such as Morningstar's version,
then they should be able to get a free upgrade from Morningstar for CCP.
If you are running pppd on both systems then you should use the 2.2 code
on both systems.
or, if the peer refuses to listen to you or you can not convince them as
to the errors of their ways,
2. Edit the pppd code so that it does not attempt to send CCP frames. If you
do this then you will also prevent the PPPD process from using CCP.
If you choose to do this, then edit the main.c code and comment/delete
the call to the ccp_open() function. In addition, you will need to
comment/delete the CCP protocol entry in the protab[] list near the
top of the file.
[duplicate log entries were deleted]
> Mar 19 13:21:18 wxsat pppd[4571]: sent [CCP ConfReq id=0x1 <bsd v1 12>]
> Mar 19 13:21:18 wxsat pppd[4571]: rcvd [LCP ProtRej id=0x5 80 fd 00 07 15 03 2c]
> Mar 19 13:21:29 wxsat pppd[4571]: sent [LCP EchoReq id=0x0 2a 18 c8 ab]
> Mar 19 13:21:29 wxsat pppd[4571]: rcvd [LCP EchoRep id=0x0 eb b4 e6 fd]
> Mar 19 13:24:40 wxsat pppd[4571]: sent [LCP EchoReq id=0x1 2a 18 c8 ab]
> Mar 19 13:24:55 wxsat pppd[4571]: ioctl(PPPIOCGIDLE): I/O error
> Mar 19 13:24:55 wxsat pppd[4571]: ioctl(TIOCSETD): I/O error
> Mar 19 13:24:55 wxsat pppd[4571]: ioctl(TIOCNXCL): I/O error
> Mar 19 13:24:55 wxsat pppd[4571]: Exit.
>
> The 15 second interval appears to be observed but where are the 16
> tries??? What's going on in the exchange at 21:29 - what's being said
> in the request and reply (and why doesn't the request get echoed back
> as the reply)?
It does. However, it is the peer system which sends the EchoRep to the
second EchoReq. It had given up on the link because of the CCP frame
by that time.
As to the four bytes which follow the request/reply, from RFC 1661 . . . . :
5.8. Echo-Request and Echo-Reply
Description
LCP includes Echo-Request and Echo-Reply Codes in order to provide
a Data Link Layer loopback mechanism for use in exercising both
directions of the link. This is useful as an aid in debugging,
link quality determination, performance testing, and for numerous
other functions.
Upon reception of an Echo-Request in the LCP Opened state, an
Echo-Reply MUST be transmitted.
Echo-Request and Echo-Reply packets MUST only be sent in the LCP
Opened state. Echo-Request and Echo-Reply packets received in any
state other than the LCP Opened state SHOULD be silently
discarded.
A summary of the Echo-Request and Echo-Reply packet formats is shown
below. The fields are transmitted from left to right.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic-Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+
Code
9 for Echo-Request;
10 for Echo-Reply.
Identifier
On transmission, the Identifier field MUST be changed whenever the
content of the Data field changes, and whenever a valid reply has
been received for a previous request. For retransmissions, the
Identifier MAY remain unchanged.
On reception, the Identifier field of the Echo-Request is copied
into the Identifier field of the Echo-Reply packet.
Magic-Number
The Magic-Number field is four octets, and aids in detecting links
which are in the looped-back condition. Until the Magic-Number
Configuration Option has been successfully negotiated, the Magic-
Number MUST be transmitted as zero. See the Magic-Number
Configuration Option for further explanation.
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.
The "Magic-Numbers" (the four bytes) are unique relative to each
side. They are not the "Data" area.
--
Al Longyear longyear@netcom.com longyear@sii.com
Finger longyear@netcom.com for PGP public key.
