Can't cu with mgetty(+fax) v1.0.0

• Messages sorted by:[ date ][ thread ][ subject ][ author ]

> 
> Hello again,
> 
> Many thanks to all that responded to my first posting. Unfortunately, I
> still have not been able to solve my problem. Here is some more
> information that might be useful/interesting (my dial-out device is
> /dev/ttyS2 in all cases):
> 
> 1. Location of lock files
> 
> Mate Wierdl wrote:
> > Perhaps you have Redhat Linux, you installed the mgetty.rpm which is
> > not properly configured. The problem is that the lock files of mgetty
> > are put in /var/lock/uucp while minicom or seyon puts theirs in
> > /var/lock. Apparently, the Linux F. Standard says that the lock files
> > should go to /var/lock. You can check /usr/doc/mgetty*/policy.h to
> > find out where mgetty puts its lockfiles.
> > 
> 
> When dialing out, cu seems to correctly create a lock file in
> /var/lock/LCK..ttyS2. I built mgetty from source on Slackware Linux
> 3.1.0 (kernel 2.0.26) with a policy.h file that uses the following
> #define for linux:
> 
> # ifdef linux
> # define LOCK	"/var/lock/LCK..%s"
> # endif
> 
> So the locations for the lock file would seem to agree. As further
> evidence of this, I notice an entry like the following entry appears in
> my mgetty log file (log_mg.ttyS2) when cu starts up:
> 
> 05/01 01:58:45 yS2 lock not made: lock file exists
> 
> Finally, seyon works fine when I configure it to dial out on
> /dev/ttyS2. It creates a binary lock file in /var/lock/LCK..ttyS2
> which my mgetty complains about (just like the docs said it would)
> since it is configured to use ASCII lock files.
> 
> 
> 2. Ownership/rights of /dev/ttyS2 and /usr/bin/cu
> 
> William H Nolte wrote:
> > 
> > I am using mgetty-1.1.0 with cu from Taylors v1.06.1 and they work
> > fine together. You need to be aware of a couple things to get them
> > to co-exist though. With the defaults that come with mgetty the
> > ownership and group settings of /dev/ttyS? are changed to:
> > 
> > crw-rw---- 1 uucp  modem 4, 66 May 3 23:34 /dev/ttyS2
> > 
> > when mgetty starts. Therefore, you must set the ownership and group
> > on /usr/bin/cu to match. Mine are set for:
> > 
> > - -rwxrwsr-x 1 uucp  modem 114537 Nov 25 1995 /usr/bin/Cu
> > 
> 
> These are the settings on my system; I believe they are correct:
> 
> crw-rw-r-- 1 root  uucp  4, 66 May 6 21:07 /dev/ttyS2
> -rwxr-sr-x 1 root  uucp  114537 Nov 25 1995 /usr/bin/cu*
> 
> They seem to be consistent with the settings in my mgetty.config file:
> 
> # use these options to make the /dev/tty-device owned by "uucp.uucp" 
> # and mode "rw-rw-r--" (0664). *LEADING ZERO NEEDED!*
> port-owner root
> port-group uucp
> port-mode 0664
> 
> 
> BTW, in addition to also making the point about location of lock
> files, Gert Doering wrote:
> > 
> > > Here is a sample cu session with debugging turned on that illustrates
> > > this behavior (a ^C was used to terminate the session):
> > >
> > > # ./cu -d modem
> > > ./cu: fconn_open: Opening port modem (default speed)
> > > ./cu: fconn_set: Changing setting to 0, 0, 2
> > > ./cu: fcsend: Writing "ATZ\r" sleep
> > 
> > 
> > *modem*? I thought you were talking about "ttyS2"? Do not ever (!!) use
> > /dev/modem unless mgetty is *ALSO* using /dev/modem!!
> > 
> 
> Sorry for the confusion on this one. In my Taylor configuration
> files, "modem" is an alias for a system that establishes a connection
> (without dialing) directly to my modem via /dev/ttyS2, not /dev/modem.
> (It's a trick I learned from my sys admin at work.)
> 
> In summary, my problem remains. Even though the lock file seems to
> get created and recognized correctly, and cu doesn't complain about
> permission problems, cu's reads and writes to /dev/ttyS2 don't seem to
> happen properly. In other words, I never see an "OK" prompt come back
> from the modem after the "ATZ\r" shown above. (Things that I type in
> the terminal window do echo, however.)
> 
> Any ideas, suggestions, hunches or even guesses would be happily
> enternained at this point. Thanks.
> 
> <ED>
> 

This sounds suspiciously like you have the modem configured for hardware
flow control and there is a signal missing in the cable.

If you are using RTS/CTS handshaking, and RTS is not HIGH ( which it 
should be when you CU to the port ), then I have seen occasions where
exactly what you describe happens. The modem echos back any typed
characters, but they are ignored because the RTS signal indicates that
the computer is not ready to go.

This is a VERY rare case, but I thought I might mention it. 

I haven't followed the entire thread, but the above summary is very 
concise.

Does the modem work for CU when mgetty IS NOT running?

Good luck,
-- 
	Steve Williams, Calgary, Alberta, Canada
	Genie Computer Systems Inc.
	steve@genie96.com
.