> Here's the story.....
> For about *2 months* I've been tying to connect my two Linux boxes with
> a Null modem cable. Heres a look at the revelent line in my inittab:
> s2:45:respawn:/sbin/agetty 38400 ttyS1 vt100
> This line would generate no errors in the logfiles and 'ps ax' shows
> that the getty is runing as it should. when I go to the other box and
> run minicom or seyon or cu however, there is never a connection. ONE
> time it did get a login prompt, but then the terminal froze. finally
> aftyer a few weeks, I replaced ttyS1 in the line above with cua1.
> Everything started working! that leads to another question. I read
> these newsgroups often. I see may articles advising that we should not
> use cua? in our setup because it is not standard. then why can't I get
> ttyS? to work on my machine?
the cua* devices are designed to be used as dialout devices, especially
when you have a getty (or uugetty) running on the coresponding ttyS* device.
Here is how they interact. The getty program should wait until it sees the
DCD signal (usually from the modem, but in your case if your null modem
connects DTR/DSR/DCD together, then it will ALWAYS see it whenever DTR is
asserted, and the getty should assert DTR when it starts running). This is
an indication to the getty program that a call is soming in on the device
and that it should now lock the device and send out the login prompt for the
incoming call. While DCD is NOT present, the getty will NOT lock the device,
making it available to whatever program wants to use the cua* device to use
the modem as a dialout device.
My advice is to stick to using the tty device for your agetty program and
debug the "hang". I suspect that your null modem cable is also connecting
RTS and CTS together at each end making it impossible for your two machines
to use hardware flow control properly to limit the data transfer rate in order
to avoid getting data overruns (though I would expect partial data to be
transfered in this case, possibly with lost characters). Thry setting the
baud rate on the ports lower until you get a working connection at a lower
speed that doesn't need flow control (300, 1200 or 2400 should be good enough
for this, 9600 or higher may require flow control).
Try setting up a terminal program at each end and see how well they pass data
to each other. (Oh, I see below you're having problems doing that too....)
Quote:> Another question:
> Since cua1 works in the inittab, I just leave it there. If I start
> minicom,
> (as root or a regular user) I get permission denied /dev/modem. If I
> instead try 'cu -l cua1' howver, I get the error permission denied, all
> matching ports in use. This is of course bogus. I did a search and there
> aren't any lock files out there. it makes no difference if I am root or
> a regular user, I still get this message with cu.
Most likely your agetty process has seen the DCD signal and opened the device
(locking it, whether or not a lock file actually exists). Look at the
output of "ps -augx" and check the controlling terminal column to see what
process has the serial device open. I'm betting its the agetty.
Here's my dialin line while its waiting for a call in:
root 2494 0.0 0.0 96 0 ? SW Sep 19 0:00 (uugetty)
The controlling terminal column is the one with the ? in it. My uugetty hasn't
yet locked the serial line becuase there is no incoming call. If your's
is locked to a device, then that device is locked. Whether or not there is
a lockfile in the filesystem somewhere!
Quote:> Here's a look at cua1 permissions:
> crw--w--w-
> when I change the permissions to crw-rw-rw- cu works just fine!
As far as I know, most terminal emulation programs are owned by group uucp,
and are set-gid as well. The dialout devices should allow rw group access
to the group uucp. This allows anyone running one to use the cua* device
for dialout. If you don't want to make these ports available to just anyone
on your system, then restrict access to the terminal programs.
My ports are rw-rw-rw- root uucp, but they only need to be rw-rw----.
(I'm not worried about ANY of my users using the dialout ports, its just
me and my family!)
Quote:> I'm trying to understand what going on here, but I'm having a tough time
> of it.
> I doubt that the permissons for cua1 were incorrect, because I connect
> to the net routinely using ppp. (run as root).
But root has access to the ports (as long as they are free).
Quote:> If you can give me a hand here, I appreciate it. I have ALL the howtos
> and the network administators guide and I still can't figure this one
> out. I'm trying to learn unix for my job and it's going pretty well.
> this problem has me stumped though. Your experience and insight would be
> appreciated.
There is nothing special to Linux in your problem here. Things are this
way in almost every Unix system out there today. Managing a UUCP link
has taught me a LOT about how the serial ports are managed and how they
interact with the rest of your software.
My "cu" program is owned by the user uucp, and has permissions r-sr-xr-x.
That allows it access to my dialout devices (it runs as "uucp" and uucp
has rw permission to the ports).
The solution to your problem? I would use a "partial NULL-modem" cable,
or a FULL modem cable between your to machines. After all, you don't want
to even try to establish a connection between the two machines unless BOTH
have activated their serial ports. Make sure that each machines DTR line
is connected to DSR/DCD on the remote machine, and cross RTS/CTS between
the machines in order to use hardware flow control (this is FULL modem
as far as I am concerned). If you want to use a NULL-modem, I still
recommend crossing RTS/CTS between the machines (the partial part) in
order to support hardware flow control between them, otherwise you run
the risk of dropping data, even with 16550 UARTs, at speeds of 38400 and
above.
I also recommend debugging your setup at lower speeds to eliminate a
possible extra variable from your problem set. You can up the speed later
after your connection works.
Good luck!
--
Kevin J. Cummings Peritus Software Services, Inc.
--
Kevin J. Cummings Peritus Software Services, Inc.
by