SUMMARY: Connecting modem to a SPARCstation (plus a question on slip)

From: hansen@SCR.SLB.COM
Date: Thu Nov 05 1992 - 19:08:28 CST


To: PSI%sndsu1::eecs.nwu.edu::sun-managers
Subject: SUMMARY: Connecting modem to a SPARCstation (plus a question on slip)
Cc: hansen

Last week I asked how to connect a modem to a SPARCstation, here's a summary
of the replies I got. My original question follows further down, followed
by some of the replies. And I've never got this many `mee too's before - do
so many people really have problems with their modems? Gosh - when will these
things become simple...?

The winners for me were Brian Bartholomew <bb@math.ufl.edu> and
poffen@sj.ate.slb.com (Russ Poffenberger) who suggested ditching `tip' for
`kermit'. I thought `kermit' was just a file transfer protocol - had no idea
that it was a useable comms program too... Cheers guys.

So: I connected the modem to serial port B with the cable which came with the
Sun (had to use a normal gender changer), started up `kermit' from an `xterm'
(cmdtool apparently isn't the best thing to use), and typed the commands
`set line /dev/ttyb', `set speed 9600' and `connect'. I was now connected to
the modem which answered `OK' when I typed `at'. Just what I wanted!

The answer to whether SLIP comes with SunOS is `no', but there are many PD
implementations around. PPP was recommended instead of SLIP.

Thanks to:
ekurgpol@develop-law.usc.edu
Brian Bartholomew <bb@math.ufl.edu>
poffen@sj.ate.slb.com (Russ Poffenberger)
Bob Reardon - reardon@sws.slb.com
mike%trdlnk@uunet.UU.NET (Michael Sullivan)
webber@world.std.com (Robert D Webber)
Anatoly.Lisovsky@kamaz.kazan.su ()
Kevin Cosgrove <qiclab!solomon!kevinc>
zshouben@PCS.CNU.EDU (Zhou Shouben)
stern@sunne.East.Sun.COM (Hal Stern - NE Area Systems Engineer)
mdl@cypress.com (J. Matt Landrum)
Gareth W Davies (GECO Stavanger)
(and anyone I might unintentionally have left out...)

============= ORIGINAL QUESTION =========================================
I'm tearing my hear out over how to connect a Hayes Smartmodem 9600 to a
SPARCstation IPC. All that is required of the connection is to be able
to use Sun and an xterm as a terminal against whatever it is connected to. To
the main destination I have to dial in to, a Xyplex terminal server with
dialback is used, of security reasons:

[IPC]---[modem]-----//-----[modem]-----[Xyplex]
                                          |
                                    =============== LAN
                                    | | |
                                   VAX Sun IBM

The cable I have between the IPC and modem is the one which came with the
(actually another) Sun, part no. 530-1662-01, female 25-pin plus the usual
round 8-pin. Firstly: is this a normal serial cable? Do I have to use just
a gender changer or a gender-changing crossover adapter? Whatever I do `tip'
says `connected' but nothing more.

Secondly: does anyone have a cook-book recipe for connecting a Hayes modem
to the the serial ports (A/B) on a SPARCstation, and allowing use of normal
AT commands, the way one can with user-friendly PCs? If I follow 11.4 in the
System Admin manual I can't even get an OK from the modem. Am I wrong in
assuming that a modem can be set up to work as it did on my good old PC?
The user I promised to set up the modem for works from home - he's now
getting slightly fed up with having to come in every time he needs to work
on other systems...

Another question not really related to the problem above: does anyone know
whether SunOS comes with SLIP or whether this has to be added? A couple of
users have asked when they can start running X sessions on our computers,
from their PCs, Macs and Arcs from home. Are there any good articles/papers/
user guides anywhere about how to set this up?
----------------------------------------------------------------------------
Ove Hansen e-mail : hansen@scr.slb.com
Schlumberger Cambridge Research Tel/fax: 0223-325246 / 0223-315486
P.O.Box 153, Cambridge CB3 0HG, England (International prefix for UK: 44)
=========== SUMMARY OF REPLIES ===========================================
==========================================================================
ekurgpol@develop-law.usc.edu (Elmar Kurgpold - x05709)
I often work from home using an IPC and a Hayes 2400 modem. Mine is set up as a dial-out line only, but the method described in my Sun training manual allows for dial-in/out. Type in any line that starts with # as a command. (this is almost verbatim)

1. Modify /etc/ttytab to support the modem and dial-in device:

ttya "/usr/etc/getty D2400" dialup on remote unsecure
cua0 "/usr/etc/getty D2400" unknown off

(getty is not needed for dial-out port, only dial-in)
(also, you might want to put in std.9600 in place of D2400, but I don't think
it is critical)

2. Make the dial-out device:

# cd /dev
# ls -l ttya
  crw-rw-rw- 1 root 12, 0 Jan 25 16:30 ttya
(add 128 to the second number, 0 in this case, and use the first number and
the new second number as shown below)
# mknod cua0 c 12 128
# chown uucp cua0
# chmod 600 cua0

3. Tell init to reread ttytab:

# kill -HUP 1

4. Put this line in /etc/rc:

/usr/etc/ttysoftcar -a >/dev/null 2>&1

5. Turn off software carrier detect:

# ttysoftcar -n ttya

6. Reread ttytab:

# kill -HUP 1

That should do it. Now set up /etc/remote to have an entry for the system(s)
that you want to dial into, so you can type "tip hostname". Keep in mind
that the home user should type ~. each time after disconnecting from tip,
this caused me much grief in the early going. The only thing I am not sure
how you handle is a dial-back system.

The only SLIP I have experience with comes with PC-NFS, but I have not tried
connecting two Suns with it.

============================================================================
poffen@sj.ate.slb.com:

All I need to connect my IPX to a modem is a straight gender changer. As for
using tip, I recommend kermit as much more user friendly. You should also
probably make a dialer entry in /dev. cd to /dev and say, "mknod cua c 12 128".
This will allow it to co-exist peacefully, even if you run a getty on it
for dial-in. (This assumes ttya, for ttyb, say "mknod cub c 12 129").
If you insist on using tip, make sure you have an appropriate entry in
/etc/remote.

SLIP does not come with SunOS. There are PD implementation available. PPP
is recommended these days, unless you don't have a choice on the other end.
As far as running X over the modem, PPP is almost a must (because of the
header compression), or use Xremote (the latest Xvision X server package
for Windows 3.x offers Xremote, licensed from NCD as an add-on package).
Xremote reduces the amount of traffic that goes over the lines.
===========================================================================
Bob Reardon:

 It is not packaged with SUN OS as of 4.1.x; I haven't heard of it being
in Solaris 2 either.
 Non-commercial versions of SLIP are available via anonymous ftp; one
such source is csn.org [128.138.213.21]. After logging in, you must
cd to pub/slip.
 Concensus of users at USENIX conference this month was that the best
commercial version is from Morningstar Technology - I don't know their
address.
============================================================================
mike%trdlnk@uunet.UU.NET (Michael Sullivan):

The 25-pin end of cable looks like a normal DTE. You don't need a crossover
to connect it to a modem.

There is a bug in OpenWindows' cmdtool that prevents it from working with tip
and causes the modem to appear to be dead. If you've been trying to use tip
with cmdtool, use shelltool or xterm instead.

SLIP doesn't come with Suns, but various freely distributable versions
are available in source form from archive sites, as are various
implementations of PPP (which is much better than SLIP). We use a
commercial implementation of PPP from Morning Star Technologies here,
which I recommend since it has a lot of nice features that the free
ones lack. Morning Star's PPP also has support for SLIP, but I've
never had reason to use it in SLIP mode.
============================================================================
webber@world.std.com:

You have to set the RS-232/RS-422 jumper for the port you're using
to RS-232. The jumper is on the IPC motherboard, and the manual
describing this is the model-specific softcover manual from the
boxed set that came with the unit.
============================================================================
Kevin Cosgrove 642-2676 <qiclab!solomon!kevinc>:

Dial-out/in now works just peachy on my machine.

The biggest help to me was:

> From: (Sebastian v. Bomhard) svb@guug.de
> The first thing I'd get rid off is the /dev/ttya. I deleted it, after
> it caused me very similar trouble like you have.

Simply deleting /dev/ttya allowed my configuration to work.

Wonderful suggestions for debugging were:

> From: (Peter Gross) <pag@scg.boulder.co.us>
> If your getty is the result of your ttytab entry, then the ps listing
> for that should look like:
> 16536 ? S 0:00 - D19200 ttya (getty)
>
> note the '?' -- it doesn't get tied to a specific port until the carrier
> comes on. If it has a d0 instead, you've made a mistake.

> From: "Dean R. E. Long" <dlong@cse.ucsc.edu>
> You also need to make sure your modem only turns on CD (carrier
> detect) when an actual connect has been made. Then use cua0
> (not ttya) to dial out. When it is setup correctly, the getty
> will not be able to open ttyd0 until the modem answers a call.
> You can see that it is blocking on the open, because the tty
> for getty will show up as '?' instead of 'd0' when you do a
> 'ps'. This is the only way I know of to get dialin + dialout
> to work. So, check your modem manual on how to set Carrier
> Detect correctly.

A hint about 'tip' would seem to agree with my experience:

> From: (Carl Hage) hage@netcom.com
>
> The hayes driver for the SunOS (and Berkeley) version of tip is very
> picky about return status values and many modems will require an ATX0
> initialization. Tip does ATV0E0\r in the initialization, and then
> dials with ATDTxxxx\r. The connection will be accepted only if a '1'
> status code is reported. Many modems, including mine, report different
> values depending on the connect speed, plus report DIALING and remote
> RING status values, all of which abort the connection. Also, I had to
> set my modem to ignore characters while dialing instead of aborting.
>
> Why use tip vs cu as a terminal emulator? Because tip has ~C which can
> run generalized upload/download scripts, including reliable
> transmission with rz/sz.

Below is the setup that rendered a working dial-in/out.

1. Device ownerships and permissions.

    crw------- 1 uucp uucp 12, 128 Apr 17 00:40 /dev/cua0
    crw--w--w- 1 root wheel 12, 0 Apr 17 00:33 /dev/ttyd0

2. The modem cable must pass the carrier detect line.

3. /etc/ttytab needs the following reference. Note that references to
    ttya and cua0 are gone.

    ::::::::::::::
    /etc/ttytab (partial)
    ::::::::::::::
    #
    # name getty type status comment
s
    #
    ttyd0 "/usr/etc/getty D2400" dialup on modem

    NOTE: A couple people commented that my posting had "local" in place of
    "modem" above. That was due to clerical error on my part for
    having cut-and-pasted together the pieces of my message after I
    put things back to "semi-working". I had tried a non-local field,
    but without success originally.

4. I explicitly turned off soft carrier on ttyd0 since ttysoftcar -a never
    worked for me. Building a new kernel is not necessary.

    ::::::::::::::
    /etc/rc (partial)
    ::::::::::::::
    /usr/etc/ttysoftcar -n ttyd0 > /dev/null 2>&1

5. Set up the UUCP/cu Dialers file to reflect the desired modem
    initialization:

    ::::::::::::::
    /etc/uucp/Dialers (Partial)
    ::::::::::::::

    # Avatex 2400 (Hayes compatible)
    hayes =,-, "" \dA\pT\pE0\pV1\pM0\pL0\pX2\pQ0\pS0=2\pS2=255\p
    # THIS LINE ISN'T REALLY BROKEN -- I BROKE IT FOR THIS POSTING
    S12=255\p&C1\p&D3\p&W0\r\c OK\r \dATDT\T\r\c CONNECT

6. The ACU is /dev/cua0 in /etc/uucp/Devices and /etc/remote.

    ::::::::::::::
    /etc/uucp/Devices (Partial)
    ::::::::::::::
    ACU cua0 - 2400 hayes
    ACU cua0 - 1200 hayes
    ACU cua0 - 300 hayes

    ::::::::::::::
    /etc/remote (Partial)
    ::::::::::::::
    #
    #--------------------------------------------------------------
    # General dialer definitions used below
    #--------------------------------------------------------------
    dial2400|2400 Baud Hayes :\
    :dv=/dev/cua0:br#2400:du:at=hayes:
    dial1200|1200 Baud Hayes :\
    :dv=/dev/cua0:br#1200:du:at=hayes:
    dial300|300 Baud Hayes :\
    :dv=/dev/cua0:br#300:du:at=hayes:
    #--------------------------------------------------------------
    # UNIX system definitions
    #--------------------------------------------------------------
    UNIX-2400|2400 Baud dial-out to another UNIX system:\
    :at=hayes:br#2400:cu=/dev/cua0:du:dv=/dev/cua0:\
    :el=^U^C^R^O^D^S^Q@:ie=#%$:oe=^D:
    UNIX-1200|1200 Baud dial-out to another UNIX system:\
    :at=hayes:br#1200:cu=/dev/cua0:du:dv=/dev/cua0:\
    :el=^U^C^R^O^D^S^Q@:ie=#%$:oe=^D:
    UNIX-300|300 Baud dial-out to another UNIX system:\
    :at=hayes:br#300:cu=/dev/cua0:du:dv=/dev/cua0:\
    :el=^U^C^R^O^D^S^Q@:ie=#%$:oe=^D:

        Viola! Connecting pins 6 (DSR) and 20 (DTR) on the Sun with the
        connection between the Sun and the modem severed for these lines
        solves the problem. I now have uucico, tip, cu, and dial-in on
        one physical port (/dev/cua0 and /dev/ttyd0).

If it works and you are happy, good. You will have to use software flow
control though. I'm a little puzzled why you needed to do this, though.
If set up tip without hardware flow control, everything works fine. I
turn on flow control after tip establishes the connection when uploading.
There should be a reason why your hardware flow control is getting stuck on,
and you should be able to fix it.

============================================================================

stern@sunne.East.Sun.COM: (last but not least - thanks for the attached
                           document!)

you can run SLIP on suns, but it's not bundled - the
cslip implementation from univ.toronto is quite good.

============================================================================



This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:52 CDT