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
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
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.
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
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 asserted. 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
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).
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
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
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).
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
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
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
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.
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
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 asserted so that it can open the port. One may dial out, but
once a connection is made, the modem's CD is asserted. 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
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 user to log out which should result in the dial-in PC hanging up
the phone line as will be explained shortly. Note that this behavior
is not what happens if the user is sitting at a PC. At a PC, when one
logs out, one immediately gets another login prompt as an invitation
to log in again. But a remote user gets hung up on and must redial if
the user wants to log in again. If there was no hang-up when the user
logged out, the connection would be maintained, and the idle
connection could possibly last for hours. Ideally, there could be a
wait of a few minutes after the user logs out to provide a chance to
log in again. There doesn't seem to be any provision for this as
a modem command nor does a chat script (used with mgetty) seem to have
a command for a long delay.
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 is closed and sends a
hangup signal to the modem by negating DTR. This will only happen if
stty -a shows hupcl (hang up on close) but this should be the default.
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. Killing the user's shell also causes mgetty to
respawn and wait for the next call (if so specified in /etc/inittab).
If there is a chat-script for mgetty to initialize the modem, that
will happen also.
As an alternative to using DTR to tell the modem to hang up the phone
line, a chat-script used after mgetty respawns may send the unique escape
code sequence +++ to the modem to put it into AT command mode. The
+++ must have both an initial and final 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 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.
When DTR drops (is negated)
When DTR (the "hang-up" signal when negated) is 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
&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 asserted
again. But since mgetty automatically respawns (if so set in
/etc/inittab) then mgetty will immediately restart after a logout and
this will assert DTR. So what happens when someone logs out is that
DTR only is negated for a fraction of a second (winks) before it gets
asserted 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: 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. This results in a lost connection and of course a loss of
carrier. Other problems could also cause a loss of carrier. The "NO
CARRIER" result code is displayed. The modem hangs up and waits for
the next call. Except that there is no mgetty running yet to start the
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
negated CD signal it should kill the shell and then getty should
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, the modem ignores the negation of DTR (hang up). 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 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 asserted only when there's carrier).
Getty_em requires &C0 (CD always asserted)
&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). 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)
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
"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 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
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
The other, more advanced, but currently poorly documented, is
vgetty. It's an optional addition to the well documented and
widely distributed mgetty program. It supports ZyXEL-like voice
modem commands. In the Debian distribution, you must get the
mgetty-voice package in addition to the mgetty package and mgetty-doc
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.
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
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:
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
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
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
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