andrewd@cs.tamu.edu (Andrew Ted Duchowski) (04/08/91)
Hi,
some time ago I posted a problem with /dev/cua getting locked
("device busy"). Thanks to all those who replied.
Because some people mailed me that they were experiencing
similar problems, I'm posting somewhat of a progress report.
First of all, I hadn't configured my modem, so that was
part of the problem. I used
AT &c1 &d2 s0=6 &w0
to set up DTR and DCD correctly (s0=6 is just for number
of rings before answering) and &w0 writes to non-volatile
memory. Basically all this helped fix was the problem
of the modem not hanging up when I exitted kermit.
This did not help with /dev/cua being busy.
I found that I could use /dev/cua in single user mode
but not in multi-user. With further experimenting, I
am now logged on at school thru the modem, writing this message.
It turns out that if I had the getty sitting on /dev/ttyda,
I couldn't get hold of /dev/cua. It seems to me that
ttyda (dial in) cua (dial out) were originally designed
to somehow share the serial port (A in this case), however
ttyda seems to hold on to the port so that cua couldn't
grab a hold of it. Some say this is a 2.0 bug and I
should get 2.1 (btw, where can I get 2.1?). So effectively
what I had to do was to turn off the getty on ttyda.
(Edit the /etc/ttys file, and set the on/off field to
off; kill -HUP 1). I guess basically what this does is keeps the
port free, enabling kermit (what I'm using now) to get
a hold of cua whenever I start it up.
Now, although I can dial out, for some reason I can't
escape back to my local kermit. I'm using 4E, so
perhaps there's a problem there. I'm working on getting
kermit 5A... Is this because of the getty not being there?
I have to kill -9 kermit now. I suppose it's better than
not being able to dial out at all (or at least better
than from single user mode).
What a joke. Is there a *clean* way to iron these problems
out?
Btw, I just saw a post about the same problem. The person
said that tip and kermit don't work on /dev/cua, but rather
on /dev/cub. I don't believe it's a "port A vs port B"
problem. I'm using /dev/cua right now. One thing that
does help is being root. Even though my permissions appear
to be set up "right", ie. as the consensus dictates (/dev/cua
owned by uucp, kermit owned by uucp w/sticky bit set).
Even though kermit has the sticky bit, it still complains
about not being having permissions on lock files. This
seems to be a pre-5A problem, so I can overlook it untill
I get 5A I suppose. As far as the recent reply about this
problem and LCK..cua file, kermit ought to tell you about
it. My 4E version does.
Thanks in advance for any further help/suggestions,
Andrew
andrewd@cs.tamu.edu
--
-------------- Not an Official Texas A&M University Document --------------scott@mcs-server.gac.edu (Scott Hess) (04/11/91)
In article <14329@helios.TAMU.EDU> andrewd@cs.tamu.edu (Andrew Ted Duchowski) writes:
First of all, I hadn't configured my modem, so that was
part of the problem.
[Fixed that]
This did not help with /dev/cua being busy.
It turns out that if I had the getty sitting on /dev/ttyda,
I couldn't get hold of /dev/cua. It seems to me that
ttyda (dial in) cua (dial out) were originally designed
to somehow share the serial port (A in this case), however
ttyda seems to hold on to the port so that cua couldn't
grab a hold of it. Some say this is a 2.0 bug and I
should get 2.1 (btw, where can I get 2.1?). So effectively
what I had to do was to turn off the getty on ttyda.
We had some similar problems. The problem we were having was again
related to modem setup. Our modem was holding DTR incorrectly, and
it kept causing the machine to think the modem was ready for a login.
It worked after some more modem configuration work . . .
Now, although I can dial out, for some reason I can't
escape back to my local kermit. I'm using 4E, so
perhaps there's a problem there. I'm working on getting
kermit 5A... Is this because of the getty not being there?
I have to kill -9 kermit now. I suppose it's better than
not being able to dial out at all (or at least better
than from single user mode).
This is actually a problem with the machine, not kermit or the
modem. The problem is that the ctrl-shift-\, where \ is off
the keypad, doesn't exist on the new keyboards. There are a couple
fixes. Stuart2.11 has code to spoof this, so that your programs
(command line programs, that is). Otherwise, use kermit's 'set
escape-character' command to set the character to 29 (ctrl-],
I think). That can be added to your .kermrc file.
Btw, I just saw a post about the same problem. The person
said that tip and kermit don't work on /dev/cua, but rather
on /dev/cub. I don't believe it's a "port A vs port B"
problem.
It's not.
Later,
--
scott hess scott@gac.edu
Independent NeXT Developer GAC Undergrad
<I still speak for nobody>
"Simply press Control-right-Shift while click-dragging the mouse . . ."
"I smoke the nose Lucifer . . . Banana, banana."madler@nntp-server.caltech.edu (Mark Adler) (04/11/91)
Andrew Duchowski seems frustrated about using his modem: >> What a joke. Is there a *clean* way to iron these problems >> out? He is using kermit 4E and says he's trying to get 5A. Indeed, 5A will clean up several of the problems he is experiencing: not being able to escape kermit with the new keyboard, permissions on lock files, proper use of the lock files, and proper handling of kermit being owned and setuid as uucp. You can get kermit 5A(165) compiled for 2.0 as kermit5a.165.bin20.tar.Z in pub/next/binaries at cs.orst.edu. Also, here is an excerpt from a posting by Steve Boker containing a fix sent to him by NeXT for the lockup problem in 2.0 (fixed in 2.1): ---- quote ---- I have dialin/dialout working fine on a 68040 cube. There is also a script that you should call every 15 minutes or so from your crontab. ------------------------------cut here------------------------ #! /bin/sh -u PIDS=`ps -ax | bm getty | grep -v bm | awk '{print $1}'` kill -TERM $PIDS kill -HUP 1 ------------------------------cut here------------------------ This corrects an error state that occurs maybe on time in ten after a modem connect. A phantom LOCK is placed on the port after the modem disconnects, and further use of the port is disabled until this script is run. NeXT is aware of the problem and sent this fix to me when I brought it to their attention. ---- end quote ---- Mark Adler madler@pooh.caltech.edu
madler@nntp-server.caltech.edu (Mark Adler) (04/12/91)
In article <SCOTT.91Apr10190820@mcs-server.gac.edu> scott@mcs-server.gac.edu (Scott Hess) writes: >related to modem setup. Our modem was holding DTR incorrectly, and >it kept causing the machine to think the modem was ready for a login. >It worked after some more modem configuration work . . . The guy at TAMU was using the right modem setup (his AT commands are the same as mine) in regards to DTR and DCD, so I wonder about his cable ... Mark Adler madler@pooh.caltech.edu