On Sun, 23 Jan 2000, Evan Alter wrote:
|Don't ask me why, but now I can log on with both Seyon and Hyperterm. I
|get the "garbage" I've been reading about for so long, but then it
|disconnects with the message, "no carrier."
|So you're right, my ISP must be expecting something (a command in the
|chatscript?). Could my ISP really be expecting PAP secrets as well as a
|login/password sequence?
It certainly seems that it expects the login/password, here and in all
the logs you've posted. Still, I'm surprised that trying to do straight
PAP authentication didn't work.
|Anyway, I commented out references to PAP in the appropriate files and
|amended my chat script so the final lines read:
You could leave the PAP configuration as was, it won't stop the
login/password from occurring as long as you have it in the chat script.
|TIMEOUT 75
|CONNECT \d\c
|login [EMAIL PROTECTED]
|word *****
|
|Now, I get this from /var/log/debug (thanks for the tip):
|
|Jan 23 14:40:14 openG chat[1138]: expect (CONNECT)
|Jan 23 14:40:14 openG chat[1138]: ^M
|Jan 23 14:40:33 openG chat[1138]: ^M
|Jan 23 14:40:33 openG chat[1138]: CONNECT
|Jan 23 14:40:33 openG chat[1138]: -- got it
|Jan 23 14:40:33 openG chat[1138]: send (\d)
|Jan 23 14:40:34 openG chat[1138]: expect (login)
|Jan 23 14:40:34 openG chat[1138]: 45333/ARQ/V90/LAPM/V42BIS^M
|Jan 23 14:40:34 openG chat[1138]: Welcome to MindSpring Dialup Service^M
|Jan 23 14:40:34 openG chat[1138]: arc-6b.bos login
|Jan 23 14:40:34 openG chat[1138]: -- got it
|Jan 23 14:40:34 openG chat[1138]: send ([EMAIL PROTECTED]^M)
|Jan 23 14:40:35 openG chat[1138]: expect (word)
|Jan 23 14:40:35 openG chat[1138]: : [EMAIL PROTECTED]^M
|Jan 23 14:40:35 openG chat[1138]: Password
|Jan 23 14:40:35 openG chat[1138]: -- got it
|Jan 23 14:40:35 openG chat[1138]: send (*****^M)
|Jan 23 14:40:35 openG pppd[1137]: Serial connection established.
|Jan 23 14:40:36 openG pppd[1137]: Using interface ppp0
|Jan 23 14:40:36 openG pppd[1137]: Connect: ppp0 <--> /dev/modem
|Jan 23 14:40:36 openG pppd[1137]: sent [LCP ConfReq id=0x1 <asyncmap
|0x0> <magic 0xa932a321> <pcomp> <accomp>]
|Jan 23 14:40:39 openG pppd[1137]: rcvd [LCP ConfReq id=0x2 <mru 1500>
|<asyncmap 0xffffffff> <magic 0x7b151d0e> <pcomp> <accomp>]
|Jan 23 14:40:39 openG pppd[1137]: sent [LCP ConfAck id=0x2 <mru 1500>
|<asyncmap 0xffffffff> <magic 0x7b151d0e> <pcomp> <accomp>]
|Jan 23 14:40:39 openG pppd[1137]: sent [LCP ConfReq id=0x1 <asyncmap
|0x0> <magic 0xa932a321> <pcomp> <accomp>]
|Jan 23 14:40:42 openG pppd[1137]: sent [LCP ConfReq id=0x1 <asyncmap
|0x0> <magic 0xa932a321> <pcomp> <accomp>]
|Jan 23 14:40:42 openG pppd[1137]: rcvd [LCP ConfReq id=0x3 <mru 1500>
|<asyncmap 0xffffffff> <magic 0x7b151d0e> <pcomp> <accomp>]
|Jan 23 14:40:42 openG pppd[1137]: sent [LCP ConfAck id=0x3 <mru 1500>
|<asyncmap 0xffffffff> <magic 0x7b151d0e> <pcomp> <accomp>]
|Jan 23 14:40:45 openG pppd[1137]: rcvd [LCP ConfReq id=0x4 <mru 1500>
|<asyncmap 0xffffffff> <magic 0x7b151d0e> <pcomp> <accomp>]
This is what I tried to describe in the last mail where pppd sends
requests, the peer sends requests that pppd receives, pppd ACKs the
peer's requests, but the peer does not ACK any of pppd's requests, i.e.,
it doesn't seem to "hear" pppd's requests.
In all the cases I've seen with these symptoms the wrong UART
is configured for the modem's device file. Again, check the UART
configuration with "setserial /dev/ttyS1". The configured UART type
must be the UART type that the modem's serial port uses.
The most common type is 16550A (16550 won't work), or 16450 for older
serial ports that could do no more than about 14.4kb. The configuration
is done on boot-up in one of the /etc/rc.* files, here it's called
/etc/rc.d/serial but it varies with distribution. Read man setserial
and don't trust the setserial automatic configuration. My setserial
line for the modem's serial port configuration is
/sbin/setserial -b /dev/ttyS2 uart 16550A port 0x3E8 irq 5
since I've configured the modem's serial port, corresponding to
/dev/ttyS2, to use IRQ 5.
|What is happening? These LCP requests are represented by the "garbage"
|I see in communication programs, right? Obviously, something must come
|next, but what?
Right, that's the "garbage." See above for what's next.
|I notice there is no longer the five-minute delay I was experiencing
|before, so something must be working a little better.
Indeed! :-)
---
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]
