Board index Linux Networking

Modem dials in minicom and some versions of 'pppscript' file but not others??

Modem dials in minicom and some versions of 'pppscript' file but not others??

Post by JX » Sun, 13 Sep 1998 04:00:00



Hello, I'm having a very strange time getting one of my computers to
connect to my isp. I set up the ppscript using pppsetup. Everything went
fine on this computer and when I'm linux it dials perfectly, yet on my
other, the same script just wont even get the modem to dial. Also, the
modem dials fine under Minicom or seyon, yet it goes much much too slow
when i am typing in manually my username and pass as the ISP does not
use pap or chap at all, so the connection times out before I can issue
the pppd command.

This is the script that dials on this pc, but not the other:

TIMEOUT 10
ABORT ERROR
ABORT BUSY
ABORT "NO CARRIER"
ABORT "NO DIALTONE"
REPORT "CARRIER"
REPORT "CONNECT"
"" "AT\&FW1H0^M"
OK "atdt7704853895"
CONNECT ""
ogin: myid
ssword: mypass

I've been messing around with scripts like crazy and the following one
actually dials, but doesnt do anything because clearly something is
wrong, but I also cannot figure out WHY it DOES in fact dial?!? Script:

TIMEOUT 10
ABORT BUSY
"" "atdt7704853895"
TIMEOUT 35
CONNECT ""
ogin: user
ssword: pass

Does anyone have any advice?
Thank you,
Josh

 
 
 
Top

1. Can ISP detect when dial-ins are 'overloaded' ?


Is this really SO difficult to understand !?!
If you don't realise that internet communication via dialup
[and also not via dialup] entails a series of traffic flows,
consider the following analogy.

You plan to make a pysical journey thus:
1. collect your documents.
2. lock the house.
3. walk to the bus stop.
4. board the bus
5. walk from the bus to your destination.

If there's a bus 'strike' causing busses to be much
delayed, and you KNOW of such then you can make an
intelligent decision to re-schedule your journey to another
day/time.

Similarly the ISP's system knows that congestion is
causing an extra wait  before the client is PAP-confirmed.
And by feeding back a telco engaged signal to before
receiving modem will save their client the futile telco
connect cost.

Similarly if you KNOW that there will be a long
queue/wait at a facility, you can intelligently decide to
NOT start your 'journey' and rather 'try another time'.  
But NOT if the 'signal' is not fed back from the
over-loaded facility to the client.

2. Raw Ethernet Socket programming

3. MGETTY LOGS

4. Find PROM version on SS 1000 (and others) without 'stop-A'

5. Newer version of rpcgen for ONC RPC

6. What's 'side effects' of Ksh built-ins?

7. RewriteEngine directive problems on Solaris 2.6 with Apache 1.3.4

8. getty_ps2.0.7 Still my modem does not accepts dial-ins.

9. Can't get dial-ins, anyone?

10. IP Accounting doesn't work for PPP dial-ins :-(( ??

11. New US Robotics modem won't dial; browser won't find web pages

12. dialing program; modem receives dialstring but doesn't dial?


All times are UTC
Board index