On Thu, 3 Feb 2000, David J. Pfaltzgraff wrote:
|At 07:41 2/2/00 -0600, in reply to my request for help, Clifford wrote:
|>On Wed, 2 Feb 2000, David J. Pfaltzgraff wrote:
|>
|>|Jan 30 12:54:29 castle pppd[1721]: pppd 2.3.5 started by root, uid 0
|
|>|Jan 30 12:54:53 castle pppd[1721]: Serial connection established.
|>|Jan 30 12:54:54 castle pppd[1721]: Using interface ppp0
|>|Jan 30 12:54:54 castle pppd[1721]: Connect: ppp0 <--> /dev/cua1
|>|Jan 30 12:54:54 castle pppd[1721]: sent [LCP ConfReq id=0x1 <asyncmap 0x0>
|>|<magic 0xea3646d9> <pcomp> <accomp>]
|>|Jan 30 12:55:21 castle last message repeated 9 times
|>|Jan 30 12:55:24 castle pppd[1721]: LCP: timeout sending Config-Requests
|>
|>...
|>
|>|Jan 30 12:54:53 castle chat[1722]: atdt3015551212^M^M
|>|Jan 30 12:54:53 castle pppd[1721]: Serial connection established.
|>|Jan 30 12:54:53 castle chat[1722]: CONNECT
|>|Jan 30 12:54:53 castle chat[1722]: -- got it
|>|Jan 30 12:54:54 castle pppd[1721]: Using interface ppp0
|>|Jan 30 12:54:54 castle pppd[1721]: Connect: ppp0 <--> /dev/cua1
|>
|>My guess is that the last line of the chat script is something
|>like CONNECT '' and sends a carriage return that makes the ISP peer
|>think you are trying to do login/password. Try using CONNECT \\c or
|>CONNECT \c instead, depending on whether the chat script is on the
|>chat command line or in a file that chat accesses with the -f option.
|>
|
|That seemed like a good idea, so I checked the file and found no quotes. I
|added the \c as suggested and tried again. I saw no difference in the
|messages.
The job of chat is to allow the modems to connect and speak to one another
and then to do what's necessary to let the ISP start PPP on it's end of the
connection. Here the modems connect and pppd sends 10 LCP requests but
receives nothing from the PPP program at the ISP. This means the ISP isn't
receiving the pppd requests or that it hasn't started it's PPP. In this
case the ISP is usually not running PPP but instead presenting a prompt or
menu when this happens.
You should have seen a chat message with "send ()" just after the CONNECT
this time. This is the sign that the `\c' or `\\c' was correctly accepted
by chat to suppress the carriage return. A variation of this is to insert
a small delay by using `\d\c' or `\\d\\c', some ISPs seem to need this.
|Just as added input... Working with a neighborly sysadmin, he suggested that
|I remove all compression (nocomp and noaccomp options) just to see if that
|would have any effect. It didn't.
That's not it, there's no PPP link negotiation since the peer is not
responding to pppd's requests and pppd sees no LCP requests from the peer.
|Are there any other suggestions?
Are you sure that the ISP has already changed to PAP authentication? Did
you make any other changes to the chat script except to remove the
login/password expect-sends?
Connect with minicom but don't try to login and see if the ISP is starting
PPP. PPP-speak appears as "garbage" characters, the first of which is
always `~'.
Post exact copies the chat script and the pppd script.
Post exact copies of the new chat logs when a suggestion doesn't work,
something that may seem unimportant to you may be significant to others.
|I'm trying to find out from my ISP what type of system I'm dialling into.
|That may provide some clues, but I don't have that info yet.
Doubtful.
---
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]
