Modem-HOWTO

Next Previous Contents

Dial-in is where you set up your PC so that others may dial in to your PC (at your phone number) and use your PC. Unfortunately some use the term "dial-in" when what they actually mean is just the opposite: dial-out.

Dial-in works like this: Someone with a modem dials your telephone number. Your modem answers the phone ring and connects. Once the caller is connected, the getty program is notified and starts the login process for the caller. After the caller has logged in, the caller then may use your PC. It could be almost as if they were sitting at your monitor-console.

The caller may use a script to automatically log in. This script will be of the expect-send type. For example it expects "login:" and then (after it detects "login:") will send the users login name. It next expects the password and then sends the password, etc. Then once the user has been automatically logged in, the /etc/passwd (password file) might specify that a shell (such as bash) will be started for the user. Or it might specify that PPP is to start so that the user may be connected to the Internet. See the PPP-HOWTO for more details. The program that you use at your PC to handle dialin is called getty or mgetty. See Getty

An advanced getty program such as mgetty can watch to see if PPP is started by the PC on the other end. If so, the login prompt would be skipped, a PPP connection would be made, and login would take place automatically over the PPP connection.

12.2 What Happens when Someone Dials In ?

Here's a more detailed description of dialin. This all assumes that you are using either mgetty or uugetty. Agetty is inferior and doesn't work exactly the same (see About agetty)

For dialin to work, the modem must be listening for a ring and getty must be running and ready to respond to the call. Your modem is normally listening for incoming calls, but what it does when it gets a ring depends on how it's configured. The modem can either automatically answer the phone or not directly answer it. In the latter case the modem sends a "RING" message to getty and then getty tells the modem to answer the ring. In either case, it may be set up to answer on say the 4th ring. This means that if the call is not for the modem, one must walk/run to the phone and pick it up manually before the 4th ring. Then an ordinary conversation can take place on the telephone. If ons gets to the phone too late one will hear the high pitched tones of the modem which has answered the call.

Once the modem answers the call it sends tones to the other modem (and conversely). The two modems negotiate how they will communicate and when this is completed your modem sends a "CONNECT" message (or the like) to getty. When getty gets this message, it sends a login prompt out the serial port. Once a user name is given to this prompt getty may just call on a program named login to handle the login procedure from there on. While getty usually starts running at boot-time it should wait until a connection is made before sending out a "login" prompt.

Now for more details on the two methods of answering the call. The first method is where the modem automatically answers the call. In this case the number of times it will ring before answering is controlled by the S0 register of the modem. If S0 is set to 3, the modem will automatically answer on the 3rd ring. If S0 is set to 0 then the modem will only answer the call if getty sends it an "A" (= Answer) AT command to the modem while the phone is ringing. (Actually an "ATA" is sent since all modem commands are prefixed by "AT".) This is the second method of answering, known as "manual" answering, since the modem itself doesn't do it automatically (but getty does). You might think it best to utilize the ability of the modem hardware to automatically answer the call, but it's actually better if getty answers it "manually".

For the "manual" answer case, getty opens the port at boot-time and listens. When the phone rings, a "RING" message is sent to the listening getty. Then if getty wants to answer this ring, it sends the modem an "A" command. Note that getty may be set to answer only after say 4 "RING" messages (the 4th ring) similar to the automatic answer method. The modem then makes a connection and sends a "CONNECT ..." message to getty which then sends a login prompt to the caller. It's not all quite this simple as there are some special tricks used to allow dial-out when waiting for a call. See Dialing Out while Waiting for an Incoming Call

The automatic answer case uses the CD (Carrier Detect aka DCD) wire from the modem to the serial port to tell when a connection is made. It works like this: At boot-time getty tries to open the serial port but the attempt fails since the modem has negated CD (the modem is idle). Then the getty program waits at the open statement in the program until a CD signal is raised. When a CD signal arrives (perhaps hours later) then the port is opened and getty sends the login prompt. While getty is waiting (sleeping) at the open statement, other processes can run so it doesn't degrade computer performance. What actually wakes getty up is an interrupt which is issued when the CD line from the modem changes its state to on.

You may wonder how getty is able to open the serial port in the "manual"-answer case since CD may be negated. Well, there's a way to write a program to force the port to open even if there is no CD signal raised.

12.3 56k Doesn't Work for Dialin

If you expect that people will be able to dial-in to you at 56k, it can't be done unless you have all the following:

You have a digital connection to the telephone company such as a trunkside-T1 or ISDN line
You use special digital modems (see Digital Modems)
You have a "... concentrator", or the like to interface your digital-modems to the digital lines of the telephone company.

A "... concentrator" may be called a "modem concentrator" or a "remote access concentrator" or it could be included in a "remote access server" (RAS) which includes the digital modems, etc. This type of setup is used by ISPs (Internet Service Providers).

12.4 Getty

Introduction to Getty

A getty program (including agetty, mgetty, etc.) is what you run for dialin. You don't need it for dialout. In addition to presenting a login prompt, it also may help answer an incoming telephone call. Originally getty was used for logging in to a computer from a dumb terminal. A major use of it today is for logging in to a Linux system at a console. There are several different getty programs a few of which work OK with modems for dialin. The getty program is usually started either at boot-time or when someone dials in to your computer. It must be called from the /etc/inittab file. In this file you may find some examples which you will likely need to edit a bit.

There are four different getty programs to choose from that may be used with modems for dial-in: mgetty, uugetty, getty_em, and agetty. A brief overview is given in the following subsections. agetty is the weakest of the four and it's mainly for use with directly connected text-terminals. mgetty includes support for fax and voice mail but uugetty doesn't. But mgetty allegedly lacks a few of the features of uugetty. getty_em is a simplified version of uugetty. Thus mgetty is likely your best choice unless you are already familiar with uugetty (or find it difficult to get mgetty). The syntax for these getty programs differs, so be sure to check that you are using the correct syntax in /etc/inittab for whichever getty you use.

In order to see what documentation exists about the various gettys on your computer, use the "locate" command. Type: locate "*getty*" (including the quotes may help). Note that many distributions just call the program getty even though it may actually be agetty, uugetty, etc. But if you read the man page (type: man getty), it might disclose which getty it is. This should be the getty program with path /sbin/getty.

How getty respawns

After you log in you will notice (by using "top", "ps -ax", or "ptree") that the getty process is no longer running. What happened to it? Why does getty restart again if your shell is killed? Here's why.

After you type in your user name, getty takes it and calls the login program telling it your user name. The getty process is replaced by the login process. The login process asks for your password, checks it and starts whatever process is specified in your password file. This process is often the bash shell. If so, bash starts and replaces the login process. Note that one process replaces another and that the bash shell process originally started as the getty process. The implications of this will be explained below.

Now in the /etc/inittab file, getty is supposed to respawn (restart) if killed. It says so on the line that calls getty. But if the bash shell (or the login process) is killed, getty respawns (restarts). Why? Well, both the login process and bash are replacements for getty and inherit the signal connections establish by their predecessors. In fact if you observe the details you will notice that the replacement process will have the same process ID as the original process. Thus bash is sort of getty in disguise with the same process ID number. If bash is killed it is just like getty was killed (even though getty isn't running anymore). This results in getty respawning.

When one logs out, all the processes on that serial port are killed including the bash shell. This may also happen (if enabled) if a hangup signal is sent to the serial port by a drop of DCD voltage by the modem. Either the logout or drop in DCD will result in getty respawning. One may force getty to respawn by manually killing bash (or login) either by hitting the k key, etc. while in "top" or with the "kill" command. You will likely need to kill it with signal 9 (which can't be ignored).

About mgetty

mgetty was written as a replacement for uugetty which was in existence long before mgetty. Both are for use with modems but mgetty is best (unless you already are committed to uugetty). mgetty may be also used for directly connected terminals but doesn't have many features for this purpose. In addition to allowing dialup logins, mgetty also provides FAX support, auto PPP detection, and caller-id support. It permits dialing out when mgetty is waiting for an incoming phone call. There is a supplemental program called vgetty which handles voicemail for some modems. mgetty documentation is fair (except for voice mail), and is not supplemented in this HOWTO. To automatically start PPP one must edit /etc/mgetty/login.conf to use "AutoPPP" (has example). You can find the latest information on mgetty at http://www.leo.org/~doering/mgetty/ and http://alpha.greenie.net/mgetty/

About uugetty

getty_ps contains two programs: getty is used for console and terminal devices, and uugetty for modems. Greg Hankins (former author of Serial-HOWTO) used uugetty so his writings about it are included here. See Uugetty.

About getty_em

This is a simplified version of ``uugetty''. It was written by Vern Hoxie after he became fully confused with complex support files needed for getty_ps and uugetty.

It is part of the collection of serial port utilities and information by Vern Hoxie available via ftp from scicom.alphacdc.com/pub/linux. The name of the collection is ``serial_suite.tgz''.

About agetty

This subsection is long since the author tried using agetty for dialin. agetty is seemingly simple since there are no initialization files. But when I tried it, it opened the serial port even when there was no CD signal present. It then sent both a login prompt and the /etc/issue file to the modem in the AT-command state before a connection was made. The modem thinks all this an AT command and if it does contain any "at" strings (by accident) it is likely to adversely modify your modem profile. Echo wars can start where getty and the modem send the same string back and forth over and over. You may see a "respawning too rapidly" error message if this happens. To prevent this you need to disable all echoing and result codes from the modem (E0 and Q1). Also use the -i option with agetty to prevent any /etc/issue file from being sent.

If you start getty on the modem port and a few seconds later find that you have the login process running on that port instead of getty, it means that a bogus user name has been sent to agetty from the modem. To keep this from happening, I had to save my dial-in profile in the modem so that it become effective at power-on. The other saved profile is for dial-out. Then any dial-out programs which use the modem must use a Z, Z0, or Z1 in their init string to initialize the modem for dial-out (by loading the saved dial-out profile). If the 1-profile is for dial-in you use Z1 to load it, etc. If you want to listen for dial-in later on, then the modem needs to be reset to the dial-in profile. Not all dial-out programs can do this reset upon exit from them.

Thus while agetty may work OK if you set up a dial-in profile correctly in the modem hardware, it's probably best suited for virtual consoles or terminals rather than modems. If agetty is running for dialin, there's no easy way to dial out. When someone first dials in to agetty, they should hit the return key to get the login prompt. agetty in the Debian distribution is just named getty.

About mingetty, and fbgetty

mingetty is a small getty that will work only for monitors (the usual console) so you can't use it with modems for dialin. fbgetty is as above but supports framebuffers.

12.5 Why "Manual" Answer is Best

The difference between the two ways of answering is exhibited when the computer happens to be down but the modem is still working. For the manual case, the "RING" message is sent to getty but since the computer is down, getty isn't there and the phone never gets answered. There are no telephone charges when there is no answer. For the automatic answer case, the modem (which is still on) answers the phone but no login message is ever sent since the computer is down. The phone bill runs up as the waiting continues. If the phone call is toll-free, it doesn't make much difference, although it may be frustrating waiting for a login prompt that never arrives. mgetty uses manual answer. Uugetty can do this too by using a configuration script.

12.6 Dialing Out while Waiting for an Incoming Call

Here's what could go wrong with a simple-minded manual-answer situation. Suppose another process dials out while getty is listening for a "RING" message from its modem on the serial wire. Then incoming bytes for the dial-out process flow from the modem to the serial port. For example, your modem may send a "CONNECT" message to your serial port when the dial-out process connects. If getty reads this there's trouble since reads are destructive reads. Once getty reads it, then the dial-out process that is expecting "CONNECT" (or something else) can't read it. Thus the dial-out process is likely to fail.

There's a way to avoid this and here's how mgetty does it. When mgetty is listing for an incoming call, it doesn't read anything from the port until it thinks that the characters are for mgetty. Mgetty monitors the port and if characters arrive, it doesn't read them right away. Instead, it first checks to see if another process is using the port. If so, mgetty backs off and closes the port (but the port remains open for the other process). Thus, if another process dials out, mgetty doesn't interfere with it. When the other process finally closes the port, then mgetty resumes "listening". It's a special type of "listening" that refrains from reading until mgetty believes that what it will read is for mgetty (hopefully a "RING" message).

When mgetty checks to see if another process is using the port, it actually checks for valid lockfiles on the port. If the other process failed to use lockfiles, too bad for it. For more details see the mgetty documentation: "How mgetty works". For programmers only: "listening" is actually using the system calls "poll" or "select" to monitor the port. They are likely also used to monitor the port when a non-mgetty process is using the port.

Then there's the problem of modem configuration when using mgetty. Mgetty first sets this configuration when it starts up and uses a user-specified chat script to do it. So the modem is now configured not to auto-answer but to send the RING string to mgetty when the phone rings. Now suppose that while mgetty is waiting for an incoming call, another program makes and outgoing call and reconfigures the modem to something bad for mgetty. To prevent this, when mgetty detects that some other program using the port has exited, mgetty just exits itself. This results in mgetty starting up anew (respawns per the /etc/inittab file) and then mgetty reconfigures the modem so that it's all set up to listen once more for incoming calls.

With auto-answer (not normally used by mgetty), getty is waiting for CD to be raised so that it can open the port. One may dial out, but once a connection is made, the modem's CD is raised. If getty were to then read the port it would eat the characters intended to be read by the dial-out connection. While agetty will have this problem, it's claimed that uugetty will check lockfiles before reading (similar to mgetty).

12.7 Ending a Dial-in Call

There are two major ways to end a dial-in call. The caller may either logout or just hang up. For the hangup case see Caller hangs up

Caller logs out

When the call is over, the normal way to end the connection is for the remote user to log out. This should result in the dial-in PC hanging up the phone line as will be explained shortly. Note that this behavior is not what normally happens when one logs out from a PC (when not using a modem). In this case, the user logs out and immediately gets a login prompt as an invitation to log in again. But a remote user that types "logout" gets hung up on, and must redial if s/he wants to log in again. If there was no hang-up when the user logged out, the connection would be maintained, and not give anyone else the opportunity to login.

Logging out by the remote user of your dial-in PC will kill the shell that the remote user was using on your dial-in PC. Now, since there is nothing running on this port anymore, the port closes and sends a hangup signal to the modem by negating DTR. This will only happen if stty -a shows hupcl (default). hupcl = Hang UP on CLose => drop DTR (the "hang up" signal) when the last program running on this port is closed). But normally, when the shell is killed it's like getty was killed and getty will respawn (since it's set this way in /etc/inittab). This will almost immediately open the port again and raise DTR. So DTR is said to wink (drop only for only a small fraction of a second and then reassert itself). With modern fast computers, this wink would be too short to be recognized by the modem so the serial driver is supposed to make this wink longer (provided stty has hupcl set, and provided ...). But there was a complaint in 2003 that it's not long enough.

The dial-in PC modem getting the hangup (negated DTR signal) will then hang up the phone line (provided the modem has been configured to do this --see below). The modem should then be ready to answer any new incoming calls. For mgetty, if there is a chat-script to initialize the modem and possibly reset the modem will happen also. If the modem didn't hang up due to too short of a DTR wink, then a newly spawned getty might be able to hang up. mgetty itself creates a long DTR wink when it starts up to hang up the modem. It's claimed that making a respawned getty clean up the mess (the modem still online) left by the previous call, is not the right way to handle this.

When setting up mgetty, one may use a chat-script with the code sequence +++ to the modem to put it into AT command mode if DTR didn't work. The +++ must have both an initial and final minimal time delay. Once in AT command mode, a hangup command (H0) may be sent to the modem as well as other AT commands. One may have things set up to use both this method and the DTR method and so that if one method should fail, the other one will hopefully work. If the PC fails to successfully signal the modem when a logout happens (or fails to use the +++ escape when restarting getty), then the modem is apt to remain in on-line mode and no more incoming calls can be received. It's claimed that this might be a security risk.

When DTR drops (is negated)

When DTR (the "hang-up" signal when negated) is dropped (negated), what the modem does depends on the value of the &D option in the modem's profile. If it's &D0 nothing at all happens (the modem ignores the negation of DTR). Here's what happens when the computer drops DTR:

&D2: The modem will hang up and go into AT command mode (off-line) to wait for the next call. Except that it will not be able to automatically answer the phone until DTR is raised again. But since mgetty automatically respawns (if so set in /etc/inittab) then mgetty will immediately restart after a logout and this will raise DTR. So what happens when someone logs out is that DTR only is negated for a fraction of a second (winks) before it gets raised again. During this wink, the DTR must be negated for at least the time specified by register S25, otherwise the modem will not hang up.

&D3: or S13 = 1. In this case the modem does a hard reset when DTR drops: It hangs up and restores the saved profile as specified by &Y. It should now be in the same state it was in when first powered on. But mgetty may have a chat script which will send the modem an init string and thus change the profile again. Since these two changes in profile happen at about the same time, could this be a problem (known as "race conditions").

The S25 limit may have no effect so even a very short DTR "wink" is detected. Another brand of modem says the S25 limit is still valid. Thus &D3 is a stronger "reset" than &D2 which doesn't restore the saved profile and could require a longer wink to work.

Under favorable conditions, either &D3 or &D2 should work OK. It's reported that for a few modems, only &D2 works OK. Could this be related to a possible race condition mentioned above if &D3 is used?

Caller hangs up

Instead of logging out the normal way, a caller may just hang up (by closing the "terminal" program s/he's using, etc). This results in a lost connection and of course a loss of carrier. Other problems could also cause a loss of carrier. The modem hangs up and waits for the next call. Except that there is no mgetty running yet to start the login process.

Here's how getty gets started again: The loss of carrier should negate the CD signal sent by the modem to the serial port (provided &C1 has been set). When the PC's serial port gets the dropped CD signal it should kill the shell, provided clocal is negated (-clocal) and then getty should respawn. mgetty raises clocal when it starts. Does it later drop clocal?

This paragraph is about other things that happen but do nothing. Only the curious need read it. When the shell is killed, a DTR wink is sent to the modem but since the modem is not on-line anymore and has already hung up due to lost carrier, the modem ignores the drop of DTR. The loss of carrier also negates the DSR signal sent by the modem to the serial port (provided &S1 or &S2 is set) but this signal is ignored (by Linux). The "NO CARRIER" result code should be generated by the modem but where does it go to ?

12.8 Dial-in Modem Configuration

The getty programs have a provision for sending an init string to the modem to configure it. But you may need to edit it. Another method is to save a suitable init string inside the modem (see Init Strings: Saving and Recalling for how to save it in the modem).

The configuration for dial-in depends both on the getty you use and perhaps on your modem. If you can't find suggested configurations in other documentation here are some hints using Hayes AT commands:

&C1 Make the CD line to the serial port track the actual state of the carrier (CD raised only when there's carrier). Getty_em requires &C0 (CD always raised)
&D3 Do a hard reset of the modem when someone logs out (or hangs up). For some modems it's reported that &D2 is required since they can't tolerate a hard reset ??
E0 Don't echo AT commands back to the serial port. This is a must for agetty. Some suggest E1 (echo AT commands) for mgetty. For dial-out you want E1 so you can see what was sent.
&K3 Use hardware flow control
Q0 Echo results words (such as CONNECT). Most gettys use them. But it's reported an AT&T version of uugetty and agetty require Q2 (no result words for dial-in).
S0=? mgetty suggests S0=0 (manual answer) but you give the number of rings on the mgetty command line. If you set S0=3 the modem will auto-answer on the 3rd ring, etc. Agetty uses auto-answer. So does uugetty (usually).
V1 Display results (such as CONNECT) in words (and not in code)
X4 Check for dialtone and busy signal

12.9 Callback

Callback is where someone first dials in to your modem. Then, you get a little info from the caller and then call it right back. Why would you want to do this? One reason is to save on telephone bills if you can call the caller cheaper than the caller can call you. Another is to make sure that the caller really is who it claims to be. If a caller calls you and claims to be calling from its usual phone number, then one way to verify this is to actually place a new call to that number.

There's a program for Linux called "callback" that works with mgetty. It's at ftp://ftp.rug.nl/contrib/frank/software/linux/callback/ Step-by-step instructions on how someone installed it (and PPP) is at http://www.stokely.com/unix.serial.port.resources/callback.html

12.10 Distinctive Ring

"Distinctive ring" is where you want the modem to answer phone calls only for certain types of rings like long, short, long, short, etc. To do this, you first need a modem that supports distinctive ring. The Netcomm Roadster modem can be set with an AT command to do the following, for example: It will send to mgetty: DROF=14 DRON=4 RING DROF=4 DRON=2 RING ... meaning that there is a 1.4 seconds of initial silence (DROF=14) followed by .4 seconds of ringing (DRON=4) etc. RING is also reported after each ring. Note that the modem can't be set to answer a certain type of ring, it only informs the program listening on the serial port (such as mgetty) what the ring sequence is. Then if the program likes the sequence, it sends an AT command to the modem to answer the call. Unfortunately, mgetty doesn't recognize such ring sequences but there's a workaround that may work.

Mgetty only waits for a "RING" and will ignore the DRON and DROF (Distinctive Ring OFf) words. For the Netcomm Roadster modem, you can set the delay between sending DRON= and RING. For example you could set a delay of 2.0 seconds. However, if within this 2.0 second period another actual ring occurs, the modem cancels the delayed RING message and never sends it. So you might be able to set this delay so the calls you don't want the modem to answer never send a RING message to mgetty. But for the calls you want mgetty to answer, you get the interval between rings to be long enough so that "RING" is sent to mgetty and mgetty answers the call. This workaround is not always feasible, especially if the telephone company doesn't give you much choice of distinctive rings. Will the above work for other modems that support distinctive ring?

For the above modem, the AT command: AT+VDR=1,24 sets the above delay for 2.4 seconds. You can put this in an "init-chat" parameter in mgetty.config.

12.11 Voice Mail

Voice mail is like an answering machine run by a computer. To do this you must have a modem that supports "voice" and supporting software. Instead of storing the messages on tape, they are stored in digital format on a hard-drive. When a person phones you, they hear a "greeting" message and can then leave a message for you. More advanced systems would have caller-selectable mail boxes and caller-selectable messages to listen to. Free software is available in Linux for simple answering, but doesn't seem to be available yet for the more advanced stuff.

I know of two different voicemail packages for Linux. One is a very minimal package (see Voicemail Software). The other, more advanced, but currently poorly documented, is vgetty which supports all ELSA modems and the ITU v.253 standard. It's an optional addition to the well documented and widely distributed mgetty program. In the Debian distribution, you must get the mgetty-voice package in addition to the mgetty package and mgetty-doc (documentation) package.

12.12 Simple Manual Dial-In

This is really doing it manually! It doesn't even permit the caller to login but the caller may "chat" with you, etc. It's a way to answer a call without bothering to edit any configuration files for dial-in or enabling getty. To do it you run a terminal program such as minicom. Make sure it's connected to your modem by typing "AT <enter>" and expect "OK". Then wait for the call. Then you really answer the call manually by typing "ATA" when the phone is ringing. This doesn't run getty and the caller can't login. But if the caller is calling in with a terminal program they may type a message to your screen (and conversely). You both may send files back and forth by using the commands built into the terminal programs (such as minicom). Another way to answer such a call would be to type say "ATS0=3" just before the call comes in to enable the modem to auto-answer on the third ring.

This is one way to crudely transfer files with someone on a MS Windows PC who uses HyperTerminal or Terminal (for Windows 3.x or DOS). These two MS programs are something like minicom. Using this simple manual method (for Linux-to-Linux or MS-to-Linux) requires two people to be present, one one each end of the phone line connection running a terminal communications program. Be warned that if both people type at the same time it's chaos. It's a "last resort" way to transfer files between any two people that have PCs (either Linux or MS Windows). It could also be used for testing your modem or as a preliminary test before setting up dial-in.

12.13 Complex GUI Dial-In, VNC

At the opposite extreme to the simple (but labor intensive) manual dial-in described above, is one that results in GUI graphical interface to the Linux PC. This generally requires that a network running TCP/IP protocol exist between the two computers. One way to get such a "network" is to dial-out to a PC set for dial-in and then run PPP on the phone line. PPP will use TCP/IP protocol encapsulated inside the PPP packets. Both sides must run PPP and mgetty can be configured to start PPP as soon as the caller does. The caller may use a PPP-dialer program just like they were dialing an ISP. Programs such as wvdial, eznet, or chat scripts should do it.

Instead of this tiny network over a phone connection a much larger network (the entire world) is reached via an ISP. For their lowest-rate service many of them use proxy servers that will not give you access to the ports you need to use. Even if they don't use proxy servers, the IP address they give you is only temporary for the session, so you'll need to email this IP to whomever wants to reach you. If you get a more expensive ISP service, then you can avoid these problems.

One way to get a GUI interface from the remote PC is to run the GPLed program: Virtual Network Computer (VNC) from AT&T. It has a server part which you run on your Linux PC for dial-in and a viewer (client) part used for dial-out. Neither of these actually does any dialing or login but assumes that you have a network already set up. The VNC server has an X-server built in and may use Linux's twm window manager. See the article on VNC in Linux Magazine: http://www.linux-mag.com/2000-11/desktop_03.html. The AT&T site for VNC is: http://www.uk.research.att.com/vnc/.

With VNC one can also connect to remote Windows PCs, get the Windows GUI on a Linux PC, and run Windows programs on the remote Windows PC. Of course the Windows PC must be running VNC (as a server). Obviously, a GUI connection over a modem will be slower than a text-only connection especially if you run KDE or GNOME or want 16-bit color.

12.14 Interoperability with MS Windows

Once you have dial-in set up, others may call in to you using minicom (or the like) from Unix-like systems. From MS Windows one may call you using "HyperTerminal (or just "Terminal" in Windows 3.1 or DOS).

If in Windows one wants to use dial-up with a network protocol over the phone line it's called "Dial-up Networking". But it probably will not be able to communicate with Linux. For setting up such dial-in in Windows one clicks on "server" while dial-out is the "client. Such dial-in is often called "remote control" meaning that the caller can use your PC, run programs on it, and thus control it remotely.

While it's easy to call in to a text-based Linux system from MS Windows, it's not so easy the other way around (partly because Windows is not text-based and would need to put the caller into DOS where files wouldn't be protected like they are in Linux.

However Windows "Dial-up Networking" can establish a dial-in provided the caller uses certain network protocols over the phone line: MS's or Novel's (two protocols not liked by Linux). So if someone with Windows enables their Dial-up networking server in Windows 98, you can't just dial in directly to it from Linux. This type of dial-in doesn't permit the caller to run most of the programs on the host like Linux does. It's called "remote access" and one may transfer files, use the hosts printer, access databases, etc. Is there some way to interface to Dial-up Networking from Linux??

It is possible for two people to crudely chat and send files using Minicom on the Linux end and HyperTerminal on the Windows end. It's all done manually by two live persons, one on each end of the phone connection. See Simple Manual Dial-In.

At the opposite extreme, one would like to run a dial-in so that the person calling would get a GUI interface. For that a network protocol is normally used. It's possible using PC Anywhere for Windows or VNC for both Linux and Windows. But PC Anywhere doesn't seem to talk to Linux ?? Other Window programs for "remote control" include Laplink, Co-Session, and Microcom. Do any such programs support Linux besides VNC ??