Re: tlug: Compuserve and PPP

[Gaspar Sinai <gsinai@example.com>]

Hi,
inally I managed to configure Linux so that I could use the
Budapest number - which happens to be Compuserve.

At Budapest access point normal compuserve login script can not be
used, PAP authentication is used and a little modification is needed
to avoid the 7-bit problem:

===========================================================================
A Redhat Linux user should do the following:
In Control Panel -> Network Configurator -> add ppp interface (ppp1)
-------------------------------------------------------------
Phone: 06,12919999                    Budapest number from countryside
Check: Use PAP authentication
PPP Login: username@example.com
PPP Password: your-password

<DONE> -- save it.

vi /etc/sysconfig/network-scripts/chat-ppp1

modify last line from
            'CONNECT' ''
to
            'CONNECT'
(If you give a reply the Compuserve end goes 7-bit....)

===========================================================================

That's all you can: ifup ppp1

Thanks to all,
gaspar



On Tue, 2 Jun 1998, Karl-Max Wagner wrote:

> > My provider gives me an access point that I could use while I am
> > abroad. There are some catches. Now I could set it up so that
> If you are talking about Compuserve, quite a few.....
> > it works, but it seems to work only with Windows95 which is totally
> You probably talk about that proprietary stuff Compuserve provides...
> > useless for me, because all my mail stuff is on the Linux partition
> > of a dual-boot laptop. 
> > I would be glad if somebody with compuserve experience could help me. I
> No problem. I'll teach you the ropes in the following.....
> > Compuserve allience I am thinking of attaching a serial port analyzer, if
> No problem. Just come along and grab my HP1640A.....
> > What I have learnt so far is that:
> > o the access point is Compuserve
> > o When you connect it is 7-bit mode.
> > o People with compuserve accounts here converse the following way:
> > CONNECT 
> > <garbage>: +                           this swithes from 7 to 8 bit mode
> > Host Name:  CIS
> > Login ID: 12345,213/GO:PPPCONNECT      This tells them what we are up to
> >                                        but it wont work for me. It says
> >                                        'invalid login' . Yeah, my login
> >                                        is not a number.....
> > Password: <passw>
> > start pppd here.
> > 
> > So this works for Compuserve users in Linux, but it wont work for me. 
> > My Id is not a number. But in windows it works. How can I get what windows
> > does without a serial analyzer? 
> It works with Linux, too. Except if you are in Japan. In Japan
> for some political reasons they only provide full services if
> you don't use their direct access point, but only if you come
> via the "FENICS" network or if you are a subscriber with NIFTY -
> in which case you can use their access points.
> 
> Compuserve provides a listing of access point phone numbers
> somewhere (I actually forgot where - browse around). Here is
> already catc #1: the fast majority of fast access points given
> there are actually NIFTY access points - if you aren't a
> subscriber, you can't use them. All the low speed access points
> ( 2400 bit/s !!!!! - welcome to the stone age ! ) are FENICS.
> FENICS has high speed access points as well, but the trick is to
> get information about their phone numbers. Despite weeks of
> arguments Compuserve customer service was only able to provide
> me with dial in numbers in Osaka and Tokyo. I later found out
> that it isn't the fault of Compuserve, but that of FENICS - I
> found their homepage and an email address and I asked them for a
> list, but they didn't even bother to reply. Apparently they
> don't bother to talk to somebody as lowly as me - or Compuserve.
> 
> In the following I provide the login script I use for Minicom in
> Japan.
> 
> sleep 4
> send "@example.com"
> expect {
>   "HOST NAME"
>   }
> sleep 1
> send "C CIS"
> expect {
>   "User ID:"
>   }
> send "$(LOGIN)"
> expect {
>   "Password:"
>   }
> send "$(PASS)"
> 
> After you got a connection, you first wait 4 seconds. This is
> important, because the network isn't exactly very fast. Then you
> send the string @example.com ( terminated with CRLF as usual - in the
> script this is done by default ). Then you wait for the string
> HOST NAME. Then wait a second. Then you send a C CIS ( means
> "connect Compuserve", of course ). Then you wait for Compuserve
> to come back with the well known "User ID" prompt. You then send
> a <your-CIS-ID>/GO:PPPCONNECT, wait for the "Password" prompt
> and send your password. After that you quit Minicom with the
> infamous CTRL-A Q and launch your pppd ( see section "terminal
> authentication" in PPP for dummies which I posted lately ).
> 
> Strictly speaking, that @example.com stuff is only required for the slow
> access points, for the fast one you can just leave it away. On
> the other hand, it doesn't do any harm with the fast ones -
> except that it generates a "Unknown command" response - then
> everything proceeds normally.
> 
> It should be understood that such a connection is VERY FLAKY
> !!!! If you keep being kicked out all the time, decrease the
> speed with which you talk to your modem. I found out that 9600
> bit/s provide a halfways albeit very slow connection. I tried to
> track down where the problems come from and did a ping to my
> provider at home. I got any amount of duplicated packets, often
> quite far ( in time ) apart. Well, that explains it: if the DUP
> falls within the next receive window of TCP/IP it's gonna mess
> up things there with an ensuing death of pppd.....
> 
> This DUP stuff is a most alarming fact: it is downright
> pathological and normally unheard of in any decent network 
> ( I am certainly not a newbie in networking, but I have NEVER
> seen it in such an amount anywhere else ).
> 
> Again, I strongly suspect that FENICS is to blame because I've
> never seen such things happen with Compuserve outside Japan
> (althogh I am not very happy with their networking....).
> 
> Important catch: outside Japan you have to use terminal settings
> of "7E1" to log into Compuserve. DON'T DO THAT OVER FENICS!!!!
> ALWAYS USE SETTINGS OF "8N1" !!!!! If you fail to do so, you get
> nowhere.....I learned this the hard way by wasting an hour and
> quite a couple of Yens inside a hot telephone booth playing with
> the parameters under Minicom.....
> 
> Here are some decent dial in points into FENICS:
> 
> Tokyo: 57105300
> Osaka: 9443620
> Okayama: 0862214956
> Fukui: 675900
> 
> The one Compuserve lists for Niigata ( with 14400 bits/s ) is OK.
> Don't be astonished if accessing from Japan makes your
> Compuserve bill go through the ceiling: FENICS is expensive.
> 
> This should be enough to get you into Compuserve in Japan....
> 
> Now about Compuserve outside Japan.
> 
> My script to connect to Compuserve outside Japan is as follows:
> 
> send "\r"
> expect {
>    "Host Name:"
>    }
> send "CIS"
> expect {
>    "User ID:"
>    }
> send "$(LOGIN)/GO:PPPCONNECT"
> expect {
>    "Password:"
>    }
> send "$(PASS)"
> 
> It is much like the previous one, Just with the FENICS stuff
> left out. And here is that important SUPER CATCH:
> 
> Outside Japan you always log into Compuserve using a terminal
> setting of "7E1". You have that until PPP starts. PPP can only
> work with an 8bit clean connection. So inside Minicom you have
> to stick to it, but when you leave it and start up pppd locally,
> it talks to Compuserve's pppd with 8N1 !!!! This is in stark
> contrast to what I said in "PPP for dummies". If you don't know
> it, you're hosed.....
> 
> Another catch: With a normal provider, if you kill your local
> pppd, the modem connection is terminated. This doesn't work with
> Compuserve. You have to power cycle your modem.
> 
> With a PCMCIA modem this is easy: you just stop the PCMCIA
> services which ensues in turning off the power to your modem
> card. Without power, the modem is unable to hold the connection,
> of course. A bit brutal, but works well.
> 
> I'd generally dissuade to start PCMCIA during bootup: PCMCIA
> devices tend to be power hungry ( particularly modems ) and with
> no cardmgr running, they are powered down. I just start cardmgr
> by hand when needed. This way I can leave my modem plugged in
> without bothering about the power drain.
> 
> Alternatives to Compuserve: talk with your provider and ask them
> whether they are members of one of the global reach alliances
> like GRIC or IPASS. If so, have them instruct you how to log
> into another provider close to your respective location
> belonging to the same alliance. You then can login just into
> another provider closeby and he authenticates you via your home
> provider and bills him for the services provided to you. Your
> provider in turn bills you for that. Twics, for example is a
> member of GRIC.
> 
> Hope that gets you started.
> 
>                             Karl-Max Wagner
>                             karlmax@example.com
> --------------------------------------------------------------
> Next TLUG Meeting: 13 June Sat, Tokyo Station Yaesu gate 12:30
> Featuring Stone and Turnbull on .rpm and .deb packages
> Next Nomikai: 17 July, 19:30 Tengu TokyoEkiMae 03-3275-3691
> After June 13, the next meeting is 8 August at Tokyo Station
> --------------------------------------------------------------
> Sponsor: PHT, makers of TurboLinux http://www.pht.co.jp
> 

--------------------------------------------------------------
Next TLUG Meeting: 13 June Sat, Tokyo Station Yaesu gate 12:30
Featuring Stone and Turnbull on .rpm and .deb packages
Next Nomikai: 17 July, 19:30 Tengu TokyoEkiMae 03-3275-3691
After June 13, the next meeting is 8 August at Tokyo Station
--------------------------------------------------------------
Sponsor: PHT, makers of TurboLinux http://www.pht.co.jp