[2198] in linux-net channel archive
Re: LCP echo problems (again)
daemon@ATHENA.MIT.EDU (linuxsys@ssg.com)
Thu Mar 21 11:43:00 1996
Date: Thu, 21 Mar 1996 14:07:31 GMT
From: linuxsys@ssg.com
To: "Al Longyear" <longyear@netcom.com>
Cc: linuxsys@ssg.com, linux-net@vger.rutgers.edu,
Paul.Mackerras@cs.anu.edu.au (Paul Mackerras)
In-Reply-To: <199603201507.HAA00312@costello.longyear.com>
Al Longyear writes:
[...]
> > A follow-up question: is there a quick and easy way to verify that a
> > host is not handling CCP frames correctly?
>
> Technically, no. There is no way to know from just your side. You
> would need to look at the log files (if there are any) on the peer
> system.
>
> Empirically, yes. That comes with experience. I can only say that it
> is like an 'expert system'. You learn to pick up on the signatures of
> the problems.
>
> This one is fairly obvious.
>
> Linux pppd version 2.2 sends an empty CCP frame if you don't have any
> compressors defined. This is what was argued about for a few weeks on
> the IETF working group mail list. It means "I know CCP. I just don't
> want to do it." The peer system sends a protocol reject if they don't
> understand the protocol. Shortly thereafter, the line terminates. This
> happens even sometimes before the IPCP sequence completes.
>
> Sometimes, the peer will attempt to restart the IPCP sequence. In this
> case you will see that the IP layer will go down and then back up. You
> can tell this by seeing the list of the two IP addresses in the system
> log being printed twice (and not like yours where you have multiple
> entries in your syslog.conf file pointing to the same file.)
>
> Others will simply just terminate.
>
> However, the 'signature' seems to be that they all do this just after
> the Linux pppd process sends the CCP frame.
Gotit.
> It is usually accompanied by the person telling me "but it worked with
> 2.1.2!"
>
> I did argue the point with Paul Mackerras in that the pppd process
> should work like the 2.1 version if you don't have a compressor
> defined in that it should not have sent the empty CCP frame.
>
> I was overruled.
>
I'll change pppd later today (there's a small matter of doing
production work interfering with the stuff that really
matters... <grin>) and follow up with the results. For now, the basic
profile is that my ISP has a wretched record for maintaining
connections as seen in the log quoted in my initial post. I briefly
was able to access another (enlightened?) ISP with none of the
problems seen in talking with voicenet. That's pretty close to QED,
to my mind. If, as it appears, the empty CCP frame is causing
problems, real world condiderations strongly suggest an accomodation
of some sort other than hacking pppd code.
Rick
