Path: news.halcyon.com!bellevue-ip24.halcyon.com!tardiff
From: tardiff at halcyon.com (Michael J. Tardiff)
Newsgroups: halcyon.slip
Subject: Re: Invoking SLIP or PPP after Login
Date: Sat, 6 Aug 1994 13:42:41 -8
Organization: Western Star Consulting
Lines: 70
Message-ID: <tardiff.78.0080942A at halcyon.com>
References: <31qubc$48m at news.halcyon.com> <31rhh0$dsv at news.halcyon.com> <31sk69$no0 at nwfocus.wa.com>
NNTP-Posting-Host: bellevue-ip24.halcyon.com
X-Newsreader: Trumpet for Windows [Version 1.0 Rev B final beta #1]

Stuart Seelye writes:

>In article <31qubc$48m at news.halcyon.com>, <jsanchez at halcyon.com> wrote:

>>I would like to offer a suggestion that may or may not be possible with
>>halcyon's terminal servers. It would make the service more useful for me
>>if it were possible to connect and login to halcyon and then issue a command
>>if you wished to have a ppp or slip connection. I know that some vendors
>>servers allow this but not necessarily all of them.

>I agree that something like this would be useful. When logging on from
>home I can and do use PPP, but if I log on from work I can only do vt100.

>phaedrus at chinook.halcyon.com (Mark Phaedrus) writes:

>> Second, this would be useful as an option, but I wouldn't want to see it
>>become the default. The vast majority of the SLIP/PPP programs I've seen out
>>there assume that the connection will occur the way it does right now--enter
>>the username and password, and the SLIP/PPP initiation sequence immediately
>>starts. Modifying this would require these products to be scripted or
>>customized to connect successfully, which would be a major pain.

>Quite true. I'm using Internet Chameleon, which has only very basic
>scripting ability. I'm not sure if I could get Internet Chamaleon to handle
>starting PPP from a UNIX prompt.

It's possible to modify Chameleon's SLIP.INI file to handle any login
procedure.

>> (Of course, there is a way right now that you can have exactly the
>>functionality you want; just get two accounts, one SLIP and one shell. Presto,
>>problem solved. :) You can even use the SLIP account from a dumb terminal;
>>just call in, log in with the shell account, then use the "login" command to
>>switch to the SLIP account.)

There's a shade of meaning that needs to be clarified about Mark's suggestion:
if you have a SLIP and a Shell account, you have two logins on halcyon, and
you can use either of those logins via telnet, rlogin, or login; you can only
dialup the Shell account login with a dumb terminal. Now, it *is* possible to
have a Shell account with its login, then a separate SLIP login that's not
attached to a Shell account -- this, for example, is what I had when I was
doing testing for Northwest Nexus. The SLIP login got me a SLIP connection,
then I used my Shell login for POP, NNTP, or telnet access. We're always
investigating new service options; if there were sufficient interest, we could
consider a new service option that provided two server logins, one for Shell
and onefor SLIP, but only one halcyon login and associated directory and
mailbox. This would provide functionality similar to the "ask for SLIP, PPP,
or Shell on login" option that started this thread, but might be easier to
administer and lower in price than having two accounts. No promises, of
course -- this is just a tech-support guy thinking out loud.

>There are two obvious drawbacks to your suggestion, Mark:
>1. Extra accounts cost money. Throwing money at the problem is not
>desirable.
>2. I suspect that Northwest Nexus would object to users having more than
>one account. It would look like people were trying to have multiple
>identities, presumable for questionable activities.

Northwest Nexus offers SLIP+Shell as a service option: it's $37.50 a month,
25% of the combined costs of the two accounts.

>My suggestion is that the PPP should continue to kick in immediately
>after login, but if a PPP connection is not established after about 30
>seconds the PPP server could give up and let the system give the user a
>terminal connection.

That's unlikely to be unimplementable given current software, and probably not
desireable from a service or tech support point of view.

+ Michael