Re: nt dialin to Linux w/ callback

[Jeff Licquia <jeff@luci.org>]

On Sun, Feb 13, 2000 at 09:34:26AM -0600, Mark Blunier wrote:
> 
> I am trying to set up NT and Linux so that I can use a NT box
> to dial into work on a Linux box.  I want things to be as
> secure as possible, and since its a long distance number, I want
> the Linux box to hang up, then call back.  I checked the HOWTO's
> and set up the linux box, and to test to make sure everything
> works, set up another linux box to call in.  Everything works
> fine.

Heh.  Why do I feel this sense of coming calamity? :-)

> <Micro$oft_Ba$h>  Where is all the great support that is
> supposed to come with NT?  There is nothing that I can find on
> Microsofts site explaining how to set up PPP under NT, much less
> the details on how to get the system to take a call back.  The
> NT newsgroups aren't any better.  Anyone that says Microsoft is
> better supported than Linux obviously has there head so far up
> there butt, they can see the inside of there stomache.
> </Micro$oft_Ba$h>

Of course.  You didn't pay your $150 (or whatever it is these days) to 
get phone support.

(Not that they'd have any more of a clue.)

> If I change the Linux box so that it doesn't call back, I can
> get the NT box to call in and make a ppp connection, but I
> haven't figured out how to modify the NT scripts.  Best I can
> tell instead of One (1) script to do the chat session, there
> are Two (2), pre-dial, post-dial selectable by one of those
> radio buttons, and then options for allowing callback, and 
> allowing callback, but it asking if I should accept the call.
> This is what is confusing me.
>
> Under Linux, the Chatscript tells the modem to not drop the
> session when the line hangs up, makes the call, logins
> in, waits for the line to hang up and ring back, answers the
> call, then starts ppp.
> 
> Under NT, do I need to tell the modem to not drop the session
> when the phone hangs up, or is this what that callback buttons
> are supposed to do?  When the call comes back in, does the post
> dial session handle answering the call, or does NT handle that
> under do to the callback button?

Your first mistake is using chat scripts at all.  NT's support for
chat-script-type dialout is bad.  I'm not surprised that it breaks
callback.

You probably want to try mgetty on the Linux box.  Look in the docs
for the "AutoPPP" feature of mgetty.  Basically, mgetty has the power
to figure out when a brain-damaged PPP-only box is dialing in, and
switch to PPP afterwards.  (Yes, I know, you're only going to hang up
almost immediately, but bear with me.)  Then, you need to set up pppd
to authenticate the remote site.  If you're running potato, you should 
be able to hook pppd into PAM pretty easily.

Then, after authentication, have the Linux box hang up and dial back.
NT *might* work better this way.  Again, make sure that the Linux side
just runs PPP, and authenticates the peer.

This mimics how NT RAS handles the modem.  If you mimic it just right, 
the NT box won't be able to tell that you're not running NT, and the
monopoly-protection code can't kick in. :-)

> The easy answer would be to dump the NT box, but I am trying to
> connect an X session over a phone line.  I've tried using LBX, but
> the session was stil pathetically slow.  I tried using Graphons GoGlobal
> package, which provides X connectivity to an NT box, and its X
> display ran faster over the ppp connection than Hummingbirds X
> server did over the ethernet.  I was rather impressed.  Unfortunately,
> Graphon does not support the client end on the Linux side.  So
> unless someone can knows of some other way to export an X display
> using less bandwidth, I'm stuck with NT.

Here's what I do, and it works well for me:

 - Run your X session under VNC on the remote machine.

    vncserver :1

 - Start a ssh session between the two boxes, with compression turned
on, and set to forward a local port to port 5900 + <display number of
the VNC session>.  For best results, make the local port as close to
5900 as you can (but not lower).

    ssh -L 5902:localhost:5901 -C -l user remote.box.name

 - Now start the VNC client on the local machine, using the "hextile"
encoding method in "bgr233" mode (which limits color depth).  Have it
connect to a local session at <port number of the forwarded session -
5900>.

    xvncviewer -encodings hextile -bgr233 localhost:2

Once your password is entered, your X session will open in its own
window.

This does require you to have Linux on both ends.  The part that is
missing for NT is the ssh forwarding.  You actually can use an
intermediate Linux box to handle the ssh forwarding on the remote
side, and connect to an NT/9x remote machine using ssh compression,
but you can't use NT on the local end without ssh forwarding.
(Shucks. :-)

Performance is a little slow, but not too bad.  The bgr233 mode limits 
color depth to 8, so your color rendering is going to suck.

--
To unsubscribe, send email to majordomo@luci.org with
"unsubscribe luci-discuss" in the body.