(E-Mail Removed) writes:
> Now, years later, I want to have a portable [to move to other
> telco-connections] PC-inet connection, just for emergencies.
> A 4Mb Compaq which has had Win 3.1 installed for years
> should Inet-connect [again] except that my ISP parameters are
> now different.
Perhaps it doesn't help much here, but running antique software on the
Internet is probably not a good choice.
> atdt340-7501
> CONNECT/ARQ
> CChecking authorization, Please wait...
> username:
> Script aborted
That sure doesn't look good. "Script aborted" probably means that the
dialing script (whatever is configured here) failed to handshake with
the peer, so you *don't* have a usable connection. This is likely not
a PPP problem.
Moreover, it's not good that the system you're using started PPP
anyway right after the dial-up script failed. That's not right; it
should have aborted on error rather than driving on and causing
confusion.
Most likely, your script is set up to expect a "Username:" or "login:"
prompt, and your ISP no longer does that, but instead expects you to
start PPP immediately after the modem connects. Most ISPs are run
like that these days. (But that's just a guess; the script could have
other problems.)
> PPP[C021] SND CONFREQ ID=01 LEN=24 MRU(05DC) ACCM(00000000) \
> MAGIC(00A48D1D) PFC ACFC
Ick. The implementation you're using is requesting the default MRU.
That means it's a pretty confused implementation of PPP.
> PPP[C021] SND CONFREQ ID=0A LEN=24 MRU(05DC) ACCM(00000000) \
> MAGIC(00A5001D) PFC ACFC
Repeated LCP Configure Request messages (C021 SND CONFREQ above) with
nothing else in the log means that the local system is receiving *no*
valid PPP messages at all from the peer. Possible problems include:
- The peer isn't running PPP at all. I suspect that's the case
here, because of the script failure above.
- The local or remote modem is misconfigured so that some characters
don't pass. Except for hex 00 through 1F, a usable PPP link must
be 8-bit clean.
- There are serious serial line problems, such as wrong bit rate,
incorrect character length/parity/stop bits, or broken flow
control.
Though hardware problems could cause the above symptoms, I don't
suspect that immediately.
> ======== end of PPP trace =======
> I think someone who knows the pp-protocol could immediately
> diagnose the problem from the above trace?
It doesn't look like a PPP problem.
--
James Carlson, KISS Network <(E-Mail Removed)>
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677