[comp.sys.next] modem setup

Garance_Drosehn@mts.rpi.edu (03/26/91)

Well, I hate to admit it, but I'm having some trouble figuring out how to hook
up a modem on my Nextstation.  It may very well be that I'm just not familiar
enough with Unix, or it may be that I'm just missing something obvious.  If
anyone can help me with the following, I'd appreciate it.

The objective is to be able to use a modem to call other computers.  No UUCP
stuff (not yet, at least), I just want to dial out of the next and dial into
another computer.  I don't want the Next to accept incoming calls (not yet...).
 The modem I have is an EMAC 2400 baud modem.  I have a modem cable I bought
from NextConnection.  I won't mind if the eventual answer is "you can't do it
with an EMAC modem", but I don't want to buy a second modem until I know that
for sure.

So I look at the attaching modems section in chapter 13 of the network and
systems administration book.  Step #1 is says "Setup the modem parameters as
follows...".  Bingo, I'm already stuck.  As far as I can see, the only way to
setup the modem parameters is from software running on the machine it's
connected to.  How do I get the Next to send the commands to the modem?  How do
I get it to print out the modem configuration?

Okay, I say to myself, let's assume the modem is already set right.  Skip down
to step #4.  It says:

edit /etc/ttys so the line begining with ttyda looks like:
    ttyda "/usr/etc/getty std.<baud>" dialup on
or
    ttyda "/usr/etc/getty D<baud>" dialup on

Fine.  Presumably there is a difference between those two options.  How do I
decide which one I want?  Well, in my case I'm using serial port "b" (I had
skipped over "a" because I thought I wanted that reserved for something else). 
So I just tried changing the "ttydb" line to have "/usr/etc/getty D2400".  I
also left it as "unknown" instead of the recommended "dialup" (I just now
realized I did that...).

I go off and read the man pages for "ttys" and "tset", and don't have a clue
what they had to do with setting up a serial port for dialing out via a modem.

Now on step #5, I do the "kill -HUP 1".  I didn't read the man page for "init"
as that step suggested...

Now on to step #6.  It tells me to use /dev/cua to dial out (but I assume that
for my purposes I really want /dev/cub).  It then tells me to read the man page
for "zs".  I read it.  I have no idea what it's trying to tell me to do.  I
think I'm supposed to do a:
         /dev/cub zs 2 init zsintsetup
but that seems like an awfully weird thing to do.  Being game I try it.  Of
course it doesn't do anything but tell me "permission denied".  From my sketchy
unix knowledge it seems reasonable that that was a stupid thing to do, but that
leaves me with the question: What was I *supposed* to do?

Step #6 also mentions "tip", which sounds more like I want to do.  I read the
man pages for "tip" and "remote".  I add to /etc/remote the following:

dial2400|2400 baud hayes attributes:\
    :dv=/dev/cua:br#2400:at=hayes:du:

which is simply a copy of the "dial1200" entry with all 1200's changed to
2400's.  Note that I forgot to change the device from /dev/cua to /dev/cub...

I then try a   tip -v dial2400
it replies "missing phone number".  Hmm, good point.

I try a   tip -v dial2400 8989

and the modem starts blinking away furiously.  Unfortunately the tip command
itself says "cannot synchronize with hayes..." twice and then ends with "call
failed".  The modem keeps blinking away (send and transmit lights).  My guess
at this point is that the modem was not setup correctly, which isn't too much
of a surprise.  About this time I realize the entry in /etc/remotes was
pointing at the wrong serial port.  There is *nothing* on serial port A, so how
is it that the tip command caused *any* reaction in the modem attached to port
B?

If I change that entry to /dev/cub (and reboot) then absolutely nothing happens
when I try the tip command.  I get the same error messages, but no lights blink
on the modem.

At this point I'm confident that I haven't a clue what is going on...

Suggestions welcome.  I do have an ethernet connection on my Next, so I have
picked up NextAnswers but I didn't see any helpful hints in there.  I've read
the man pages for a half-dozen other things that seemed related, but didn't
figure out anything from that exercise.  I can pick up Kermit if that's the
right answer.  The FAQ-list says something about a very useful c.s.next usenet
article that was posted by Mark Adler on January 5th on this subject, but my
site doesn't keep articles around for that long.

If you have any insights on what I'm supposed to be doing here, please send to
   Garance_Drosehn@mts.rpi.edu
or, if you're adventurous, you can send next-type mail to:
   gad@eclipse.its.rpi.edu
I can read mail on my next, but due to some other mixups I won't be able to
reply to you if you send mail there (of course, you might consider that an
advantage...).

but I'll save that story for tomorrow's request-for-help...

Garance_Drosehn@mts.rpi.edu (03/27/91)

In article <rm6frdm@rpi.edu> Garance_Drosehn@mts.rpi.edu writes:
>Well, I hate to admit it, but I'm having some trouble figuring out how to hook
>up a modem on my Nextstation.  It may very well be that I'm just not familiar
>enough with Unix, or it may be that I'm just missing something obvious.  If
>anyone can help me with the following, I'd appreciate it.

 ...(skipping all the details of my floundering around)...

Well, several people sent me helpful messages, and I can now dial out from my
NextStation using a 2400 baud EMAC modem attached to serial port B.  Different
people suggested different solutions.  Several people passed along the detailed
message from Mark Adler refered to by the FAQ (one of those was Mark himself).

First thing I missed is that the serial port devices (/dev/cua and /dev/cub)
were permitted in such a way that I couldn't access them from the account I was
using.  I "su root"-ed and did a few chmod's to clear that up.

I then picked up file kermit5a.165.bin20.tar.Z 
from directory /pub/next/binaries
at cs.orst.edu
and installed that on my NeXT.  Using that version of kermit and some kermit
commands that were sent to me and I was up and dialing. 

Others gave me information on how to use tip & friends, and after I get some
other things done I'll see if I can get that working correctly as well.

Thanks muchly to all who responded.

  - Garance_Drosehn@mts.rpi.edu
 or gad@eclipse.its.rpi.edu    for NeXT-type mail

madler@nntp-server.caltech.edu (Mark Adler) (03/27/91)

In article <hc7f.g_@rpi.edu> Garance_Drosehn@mts.rpi.edu writes:
>First thing I missed is that the serial port devices (/dev/cua and /dev/cub)
>were permitted in such a way that I couldn't access them from the account I was
>using.  I "su root"-ed and did a few chmod's to clear that up.

Originally, I also chmod'ed the /dev/cua and /dev/cub devices, but I
don't think that's the kosher way to do it.  What I did instead is
leave the permissions on /dev/cu* the same, but made the owner of
kermit uucp (chown uucp kermit), and then gave kermit the privileges
of its owner (chmod u+s kermit).  Kermit has code in it to prevent
these privileges from applying to files that are read or written.
That is how cu and tip can access /dev/cu* (though their owner is
root, but that's not necessary).

Mark Adler
madler@pooh.caltech.edu

madler@nntp-server.caltech.edu (Mark Adler) (03/28/91)

From my own recent posting:
>> leave the permissions on /dev/cu* the same, but made the owner of
>> kermit uucp (chown uucp kermit), and then gave kermit the privileges
>> of its owner (chmod u+s kermit).  Kermit has code in it to prevent
>> these privileges from applying to files that are read or written.

Sam Finn just pointed out to me, correctly, that version 4E of C-Kermit
does not have that special code, so you should use the setuid trick
only with version 5A or later.  From the ckuker.ann file:

Summary of C-Kermit changes from 4E(072) to 5A(158)

...

  Improved use of UUCP lockfiles.
  Improved operation and security when run setuid.

The bit about UUCP lockfiles is why I think setuid is the kosher way
to do it (with 5A), since access to the /dev/cu* devices should be
restricted to programs that properly handle the uucp lock files.
These programs include uucp, cu, tip, and kermit.

Mark Adler
madler@pooh.caltech.edu