On Sat, 30 Oct 1999, Tom Zeltwanger wrote:
|I am running RedHat LINUX 6.0 and PPPD 2.3. I have a dialup PPP link that is
|working fine, but has rare, intermittent failures (described in earlier post,
|all Internet activities cease but I can still perform local area net
|functions and most command-line functions).
Intermittent problems are hard to diagnose. Sometimes they are hardware
related and those are the most elusive since software and configuration are
the first things that usually come to mind. And there are two ends of the
PPP link where they can occur.
|I have been examining the startup session (attached at end on message) and am
|trying to understand a few things. I have numbered the packets in the log as
|they were received but I reordered them to group the LCP, ICPC, and CCP
|parameter negotiations.
|Does anyone see indications of problems here? It looks like no compression
|settings are negotiated but my understanding is that this should not cause a
|failure, just poorer throughput performance.
There is no real problem with the negotiations. The presence or lack of
CCP shouldn't be a great problem with modem compression and error
correction.
The only thing that I can think of to suggest is to try the vernerable pppd
option "asyncmap a0000" which cures a surprising number of undiagnosed
transparency problems. Although usually the number of frame errors in such
cases will make the connection poor to unuseable for every connection.
|What are the strings of numbers in packets number 2, 3, 11, and 12 ? Are
|these settings that my pppd 2.3.7 do not understand? Should thins give me
|clues as to what I am connecting to? (ISP is clueless)
They are PPP options that pppd doesn't understand which have to do with
Multilink PPP and STAC LZS (CCP) compression. Particular indentification
and RFC numbers are given below. These aren't the problem but I can
recommend a book to better understand them if you'd like.
|1. pppd[264]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xc97e85a2>
|<pcomp> <accomp>]
|2. pppd[264]: rcvd [LCP ConfReq id=0x1 <asyncmap 0xa0000> <pcomp> <accomp>
|< 11 04 05 dc> < 13 0c 01 6d 61 78 6d 63 6c 65 61 6e> < 17 04 32 01>]
RFC 1990 (Multilink PPP)
11=Multilink MRRU
13=Multilink Endpoint Discriminator
RFC 2125 (Bandwidth Allocation Control Protocol)
17=Link Discriminator
[Edited]
|8. pppd[264]: sent [CCP ConfReq id=0x1 <deflate 15> <deflate(old#) 15> <bsd
|v1 15>]
|11. pppd[264]: rcvd [CCP ConfReq id=0x1 < 11 06 00 01 01 03>]
|12. pppd[264]: sent [CCP ConfRej id=0x1 < 11 06 00 01 01 03>]
RFC 1974
11=STAC Electronic LZS
|15. pppd[264]: rcvd [CCP ConfRej id=0x1 <deflate 15> <deflate(old#) 15>
|<bsd v1 15>]
|16. pppd[264]: sent [CCP ConfReq id=0x2]
|17. pppd[264]: rcvd [CCP ConfRej id=0x2]
The ISP and pppd have no common CCP algorithm, very common. Adding
the pppd option noccp will cause pppd to reject the CCP protocol and
thus any CCP negotiation, recommended.
---
Clifford Kite Not a guru. (tm)
-
To unsubscribe from this list: send the line "unsubscribe linux-ppp" in
the body of a message to [EMAIL PROTECTED]
