New HOWTO: Modem-HOWTO - page 13

Table of Contents

  12.  Dial-In

  12.1.  Dial-In Overview

  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 the 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 as described below (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, which allows one to walk/run to the
  phone and pick it up manually before the 4th ring.  One would do this
  if they expect that the call is a voice call from a real person (and
  not from another modem).

  Once the call is answered, your modem 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 logging in
  from there on.  getty usually starts running at boot-time but 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.  For
  the first method where the modem automatically answers the call, 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 it's 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 known
  as "manual" answering since the modem itself doesn't do it
  automatically (but getty does).  Since it's not really manual,
  "manual" appears in quotes.  You might think it best to utilize the
  ability of the modem 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.

  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
  perfomance.  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 asserted.
  12.3.  56k doesn't work

  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:

  1. You have a digital connection to the telephone company such as a
     trunkside-T1 or ISDN line

  2. You use special digital modems (see ``Digital Modems'')

  3. 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

  12.4.1.  Introduction to Getty

  getty is the program you run for dialin.  You don't need it for
  dialout.  In addition to presenting a login prompt, it also may help
  answer the telephone.  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 console.  There are several different getty programs but
  a few of these work OK with modems for dialin.  The getty program is
  usually started at boot-time.  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.  Hopefully these examples will be for the flavor
  of getty installed on your PC.

  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 has support for fax and voice mail but Uugetty
  doesn't.  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.


  12.4.2.  Getty "exits" after login (and can respawn)

  After you log in you will notice (by using "top" or "ps -ax") 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.  Then 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.  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 will also happen (when 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 while in "top" or with the kill
  command.  You will likely need to kill it with signal 9 (which can't
  be ignored).



  12.4.3.  About mgetty

  mgetty was written as a replacement for uugetty which was in existence
  long before mgetty.  Both are for use with modems.  mgetty may be also
  used for directly connected terminals.  In addition to allowing dialup
  logins, mgetty also provides FAX support and auto PPP detection.
  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 enable "AutoPPP" You can
  find the latest information on mgetty at
  http://www.leo.org/~doering/mgetty/ and
  


  12.4.4.  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''.


  12.4.5.  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  .
  The name of the collection is ``serial_suite.tgz''.


  12.4.6.  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.


  12.4.7.  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 using a configuration
  script.


  12.6.  Ending a Dial-in Call

  12.6.1.  Caller logs out

  When the call is over the normal way to end the connection is for the
  user to log out.  This will kill the remote user's shell on your PC.
  As a result, getty will respawn and a hangup signal (negates DTR) will
  be sent from your serial port to the modem.  This will only happen if
  stty -a shows hupcl (hang up on close) but this should be the default.
  The modem getting this 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 causes getty to respawn and
  wait for the next call.

  As an alternative to using DTR to tell the modem to hang up the phone
  line, a script used after getty 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.  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.


  12.6.2.  When DTR drops (is negated)

  When DTR (the "hang-up" signal) 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).

  &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 automatically answer
  the phone (if it should) until DTR is asserted again.  But since getty
  is set to respawn (in /etc/inittab) then getty 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.  The DTR must be negated
  for at least the time specified by register S25.

  &D3: In this case the modem does a hard reset: 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 and it's ready for
  incoming calls.  The S25 limit may have no effect so even a very short
  "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.

  If you don't know which of the above two to use try using &D3 first.
  Under favorable conditions, either one should work OK.  It's reported
  that some modems require &D2.


  12.6.3.  Caller hangs up

  Instead of logging out the normal way, a caller may simply 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 getty 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 the PC's serial port gets the negated CD
  signal it should kill the shell and then getty should respawn.

  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).


  12.7.  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 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)

  �  X4  Check for dialtone and busy signal


  12.8.  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  .  Step-by-step instructions
  on how someone installed it (and PPP) is at
  


  12.9.  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 disk.  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.  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 package.  Obsolete documentation has
  been removed from mgetty but replacement documentation is lacking
  (except if you use the -h (help) option when running certain programs,
  etc.).  But one sees postings about using it on the mgetty newsgroup.
  See ``About mgetty''.  It seems that vgetty is currently not very
  stable but it's successfully being used and development of it
  continues.  If this is the latest version of this HOWTO can someone
  who is familiar with vgetty please let me know its current status.


  12.10.  Simple Manual Dial-In

  This is really doing it manually!  There's a way to answer a call
  without bothering to edit any configuration files for dial-in or
  enabling getty but the caller can't login.  To do this you run a
  terminal program such as minicom.  Make sure it's connected to your
  modem by typing "AT " 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 minicoms).  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.11.  Complex GUI Dial-In, VNC

  At the opposite extreme to the simple (but labor intensive) manual
  dial-in 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:
  .  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
  color.


  12.12.  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 ??