On Sun, 16 Apr 2000, A.Iakovlev wrote:
|I am experiencing a lightly strange problem with my ppp connections to a
|ISP: the connection establishes (local, remote IPs are obtaned, routing
|set up etc. - OK), but NO DATA can be exchanged with the remote end (any
|IP address, any IP-based protocol) - the frames vanish into a black
|hole... This happens with only some of the ISP's PPP servers; they have
|been unable to help so far and they say they have not seen such problem
|before...
|
|Below are joined the various data. Thank you in advance!
|
|A.Iakovlev
|
|----------------------------------
|
|Kernel version: 2.2.14
|PPPD version: 2.3.11
|
|PPPD is run as
|
|/usr/sbin/pppd -detach lock modem crtscts asyncmap 00000000 defaultroute
|usepeerdns /dev/ttyS2 115200 remotename ppp0 ipparam ppp0 linkname ppp0
|noauth debug -pap name xxxx connect /usr/sbin/chat -f
|/etc/sysconfig/network-scripts/chat-ppp0
|
|Peer type: unknown (the ISP was unable to provide it).
|Connection: modem.
|
|Log output (from a session run with the 'debug' option, captured using
|daemon.*):
|
|Apr 16 13:05:37 host ifup-ppp: pppd started for ppp0 on /dev/ttyS2 at
|115200
|Apr 16 13:06:10 host pppd[5940]: Serial connection established.
|Apr 16 13:06:10 host pppd[5940]: Using interface ppp0
|Apr 16 13:06:10 host pppd[5940]: Connect: ppp0 <--> /dev/ttyS2
|Apr 16 13:06:11 host pppd[5940]: sent [LCP ConfReq id=0x1 <asyncmap 0x0>
|<magic 0x81dcec53> <pcomp> <accomp>]
|Apr 16 13:06:11 host pppd[5940]: rcvd [LCP ConfReq id=0x1 <mru 1500>
|<asyncmap 0xa0000> <auth pap> <magic 0xc1bfdf72> <pcomp> <accomp>]
|Apr 16 13:06:11 host pppd[5940]: sent [LCP ConfNak id=0x1 <auth chap MD5>]
|Apr 16 13:06:11 host pppd[5940]: rcvd [LCP ConfAck id=0x1 <asyncmap 0x0>
|<magic 0x81dcec53> <pcomp> <accomp>]
|Apr 16 13:06:11 host pppd[5940]: rcvd [LCP ConfReq id=0x2 <mru 1500>
|<asyncmap 0xa0000> <auth chap MD5> <magic 0xc1bfdf72> <pcomp> <accomp>]
|Apr 16 13:06:12 host pppd[5940]: sent [LCP ConfAck id=0x2 <mru 1500>
|<asyncmap 0xa0000> <auth chap MD5> <magic 0xc1bfdf72> <pcomp> <accomp>]
|Apr 16 13:06:12 host pppd[5940]: rcvd [CHAP Challenge id=0x1
|<8842d663ec599e6af97f8e56ce928b83>, name = ""]
|Apr 16 13:06:12 host pppd[5940]: sent [CHAP Response id=0x1 <xxxxxxxx>,
|name = "xxxxx"]
|Apr 16 13:06:12 host pppd[5940]: rcvd [CHAP Success id=0x1 ""]
|Apr 16 13:06:12 host pppd[5940]: sent [IPCP ConfReq id=0x1 <addr
|0.0.0.0> <compress VJ 0f 01> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
|Apr 16 13:06:13 host pppd[5940]: sent [CCP ConfReq id=0x1 <deflate 15>
|<deflate(old#) 15> <bsd v1 15>]
You might as well add the pppd option noccp to eliminate the useless CCP
negotiations since pppd and the peer have no commmon CCP algorithms.
Typical for pppd and many ISPs. The PPP link will work, in almost all
instances, without any CCP algorithm negotiated.
|Apr 16 13:06:13 host pppd[5940]: rcvd [IPCP ConfReq id=0x1 <compress VJ
|0f 00>]
Huh? This was a normal log until this happened. The peer doesn't attempt
to request an address for itself, certainly not normal for an ISP.
|Apr 16 13:06:13 host pppd[5940]: sent [IPCP ConfNak id=0x1 <addr
|0.0.0.0>]
Pppd insists that the peer request an IP address.
|Apr 16 13:06:13 host pppd[5940]: rcvd [IPCP ConfNak id=0x1 <addr
|212.83.179.225> <ms-dns1 212.83.128.3> <ms-dns3 212.83.128.4>]
The peer suggests an IP address for pppd to use for the connection, and IP
addresses for DNS servers.
|Apr 16 13:06:13 host pppd[5940]: sent [IPCP ConfReq id=0x2 <addr
|212.83.179.225> <compress VJ 0f 01> <ms-dns1 212.83.128.3> <ms-dns3
|212.83.128.4>]
Pppd requests the items suggested by the peer.
[Useless CCP negotiations clipped for focus]
|Apr 16 13:06:14 host pppd[5940]: rcvd [IPCP ConfReq id=0x2 <compress VJ
|0f 00> <addr 213.41.28.195>]
|Apr 16 13:06:14 host pppd[5940]: sent [IPCP ConfAck id=0x2 <compress VJ
|0f 00> <addr 213.41.28.195>]
The peer finally requests it's IP address and pppd agrees.
|Apr 16 13:06:14 host pppd[5940]: rcvd [IPCP ConfAck id=0x2 <addr
|212.83.179.225> <compress VJ 0f 01> <ms-dns1 212.83.128.3> <ms-dns3
|212.83.128.4>]
The peer agrees to pppd's request for the items it suggested.
|Apr 16 13:06:14 host pppd[5940]: local IP address 212.83.179.225
|Apr 16 13:06:14 host pppd[5940]: remote IP address 213.41.28.195
|Apr 16 13:06:14 host pppd[5940]: primary DNS address 212.83.128.3
|Apr 16 13:06:14 host pppd[5940]: secondary DNS address 212.83.128.4
|Apr 16 13:06:14 host pppd[5940]: Script /etc/ppp/ip-up started (pid 5955)
This connection *should* be okay, despite the IPCP peer request oddity
commented on above.
I'm wasn't able to verify that the DNS addresses above are vaild, but I
found that 212.83.128.1 and 212.83.128.2 are listed as DNSs for
worldonline.fr. You should be able to stick them in your /etc/resolv.conf
and not need the option "usepeerdns."
There are different types of black holes, a symptom of incorrect DNS IP
addresses is that ping hangs. That is also a symptom of an incorrect
default route. If your DNSs are good, and your routing is good, then these
are the only other things that come immediately to mind:
The peer requests an ACCM (asyncmap) of a0000 and some PPP
implementations are broken with respect to ACCM negotiation.
This can cause trouble, often starting with the IPCP negotiations.
Try asking for the same ACCM with the pppd option "asyncmap a0000".
The peer requests a VJ header compression setting (<compress VJ 0f
01>) that differs from the VJ setting that pppd requests (<compress
VJ 0f 00>). This can cause PPP link trouble when the peer is broken
with respect to VJ negotiation, or the peer VJ implementation itself
is broken.
Try setting the pppd option "novj" to prevent VJ negotiation. Or you
can try the pppd option "novjccomp", which will cause pppd to ask for
the same VJ option as the peer requested (00). That will allow pppd to
do the same type of VJ compression as the peer requested, and *might*
cure the problem without giving up VJ compression altogether.
Just in case you aren't aware of it, VJ header compression is not related
to CCP compression.
---
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]
