[comp.sys.next] The care and feeding of your cube's modem

madler@piglet.caltech.edu (Mark Adler) (11/21/90)

Fellow NuTS (I kinda like that name),

People seem to be having problems getting their modems to work, so here
is how my modem is set up and how I use it (a public service message) ...

First off, I highly recommend that you obtain and read the documentation
from NeXT in their TechSupportNotes series called SerialPortDoc.wn.  It
is complete, well-written, and even has pretty pictures of the DIN-8 and
DB-25 connectors.  (You may have to do a Command-u in WriteNow to see the
pictures.)  You can get it via anonymous ftp from cs.orst.edu in the
directory pub/next/documents/TechSupportNotes.

The modem on my NeXT works just honky-dory for both dial-in and dial-out.
I have an Everex/Abaton EverFax 24/96E.  (The fax part won't work until I
get 2.0 and a new ROM and RAM for the modem to implement a Class II Fax
command set, but that's a different story ...)


CABLING

Given that the pins on the male DIN-8 connector look like this:

     6  7  8
    3  4    5
      1  2

then my cable, which came with an EMAC (Everex) modem, is wired thusly:

   DIN-8   DB-25  signal  means                 direction
     1      20     DTR    data terminal ready   to modem
     2       8     DCD    data carrier detect   from modem
     3       2      TD    transmit data         to modem
     4       7      SG    signal ground         n/a
     5       3      RD    receive data          from modem
     6      NC
     7      NC
     8      NC
    case   case           the metal connector housings and
                          probably the cable shield also

The NeXT documentation mentioned above says that pin 8 of the DIN-8
connector should be connected to pin 7 of the DB-25 (signal ground) along
with pin 4.  Apparently this is not necessary.  Pin 8 is labeled RXD+
implying that it's a return line for pin 5 (RXD-).  Perhaps connecting
RXD+ to signal ground is necessary at baud rates higher than 9600, but at
9600, I see no errors in reception.  If you are wiring your own cable,
you should follow the NeXT directions, but if you have a cable like mine,
it'll work.

Note that pin 2 on the DIN-8 is labeled CTS (clear to send) by NeXT.
Ignore that.  It should be connected to DCD only.  I bought a $5
Mac-modem cable off a clearance table that had pin 2 on the DIN-8
connected to both DCD (8) and CTS (5) on the DB-25 end!  This cable did
not work.  (If it weren't for the RS-232 standards concerning connecting
two outputs, it might have even damaged my modem.)  If I wanted to use
this cable, I would have broken off pin 5 in the male DB-25 connector.


MODEM CONFIGURATION

The important control signals are DTR and DCD.  The modem needs to be
set up to respond to DTR and generate DCD in a specified way.  When DTR
is asserted, the modem should allow auto-answer and respond to commands.
When DTR is deasserted, it should not allow the above, and also hang up
the phone if it was off-hook.  The modem should assert DCD if and only if
a carrier is detected.

My modem's default behavior is to always assert DCD and to always ignore
DTR.  I suspect that all modems for the Mac and PC world are this way,
since modem control is not needed in most cases.  This default behavior
makes the modem/computer connection a little more robust to cable
variations.  However, it's too limited for dial-in support.

You will most likely have to read your modem manual to change this
behavior.  (Perish the thought.)  On my modem, I used the command:

     AT &C1 &D2 S0=5 &W0

The &C1 makes DCD reflect the carrier status and the &D2 makes the modem
respond as described above to DTR.  The S0=5 tells the modem to answer
the phone after five rings (the default is S0=0, which doesn't answer at
all).  Finally, the &W0 writes the configuration to the non-volatile RAM,
so the modem will always be this way when powered up.


DIAL IN

For dialing in, I changed the ttydb line (I use port B for the modem) in
/etc/ttys to:

ttydb	"/usr/etc/getty std.9600"	vt100		on

where the 9600 is the speed to talk to the modem at, vt100 says to assume
the terminal dialing in is VT-100 compatible (you can leave this as
dialup to make no assumption), and the "on" enables dial-ins.  For this
change to take effect, you will need to reboot or send a message to the
init process by:

     kill -HUP 1

Don't mess with the ttya or ttyb lines---they're for permenantly
connected terminals and do not allow sharing the port between dial-in's
and dial-out's.


DIAL OUT

For dialing out, I use Kermit 5A (4E and 4F also work fine) in a Stuart
window (Shell or Terminal also work fine, but there is no emulation in
Shell).  My kermit command line is "kermit -l /dev/cub -b 9600" where the
"b" in "cub" selects serial port B, and the 9600 is the bit per second
rate.  I use 9600 since MNP 5, which supports compression, can sometimes
require more than 2400 bps.  It is important to use /dev/cua or /dev/cub
and not any /dev/tty* to allow sharing the port for dial-in and dial-out.
You may have to change the permissions on /dev/cua and /dev/cub to be
able to use them.

You can get the kermit source via anonymous ftp from watsun.cc.columbia.
Version 4E is in kermit/b, 4F is in kermit/ck4f, and 5A is in kermit/sw.
You can get Stuart from cs.orst.edu in pub/next/binaries.  (In 2.0, the
new Terminal is a NeXT adaptation of Stuart.)

As a side note, kermit 5A supports large packets (over 9000 bytes) and
continuous transmission of packets with delayed acknowledgement, which
results in much faster transer rates when using kermit protocol
transfers.


SUMMARY

1. Make sure DCD and DTR are wired correctly on your cable, and that
   CTS isn't wired.
2. Convince the modem to respond to DTR and generate DCD appropriately,
   as well as answer the phone if it rings.  Save the setup if you can.
3. Edit /etc/ttys and put in an "on" to enable dial-in's on the port
   with the modem (ttyda for port A, ttydb for port B).
4. Use /dev/cua or /dev/cua with your communication program, NOT
   /dev/ttya, /dev/ttyb, /dev/ttyda, or /dev/ttydb.  You may have to
   chmod the permissions on /dev/cu*.

Good luck.

Mark Adler
madler@piglet.caltech.edu