garnett@cs.utexas.edu (John William Garnett) (11/21/90)
Hello... I'm having modem difficulties and hoping for some net.help: the setup -- original 030 cube, NeXTStep 1.0. the problem -- When I attempt to use NeXT's tip to dial in to a system, I usually get the following message: > /dev/cua: Device busy > link down When I attempt to use kermit 4E(072) to dial in to a system, I usually get this message: > /dev/ttya: Device busy > Sorry, can't open line: Device busy After a period of time, tip and kermit will begin to work correctly (the error messages do not appear). There doesn't appear to be any way to predict how long I will have to wait. Sometimes even powering off the machine and restarting it does not prevent the error message from occuring. I am using a Mac II serial-to-modem cable and I'm using an external Everex 24E+ (2400 baud) modem (Hayes compatible). The relevant entries in /etc/remote are as follows: dial2400|2400 Baud Hayes attributes:\ :dv=/dev/cua:br#2400:at=hayes:du: UNIX-2400|2400 Baud dial-out to another UNIX system:\ :el=^U^C^R^O^D^S^Q@:ie=#%$:oe=^D:tc=dial2400: utmicom|UT Austin Dial-in line:pn=@:tc=UNIX-2400: The relevant entries in /etc/ttys are as follows: ttya "/usr/etc/getty std.2400" unknown off secure ttyda "/usr/etc/getty D2400" dialup on Can anyone suggest a solution? Is there a way to manually recycle the port? (hopefully there is a solution that doesn't require continued manual intervention) BTW, no one else is using the machine when these messages occur. Thanks. -- John Garnett University of Texas at Austin garnett@cs.utexas.edu Department of Computer Science Austin, Texas
cbradley@blackbox.lonestar.org (Chris Bradley) (11/23/90)
In article <14903@cs.utexas.edu> garnett@cs.utexas.edu (John William Garnett) writes: >Hello... I'm having modem difficulties and hoping for some net.help: > >the setup -- original 030 cube, NeXTStep 1.0. > >the problem -- > >When I attempt to use NeXT's tip to dial in to a system, I usually get the >following message: > >> /dev/cua: Device busy >> link down > >When I attempt to use kermit 4E(072) to dial in to a system, I usually >get this message: > >> /dev/ttya: Device busy >> Sorry, can't open line: Device busy > >After a period of time, tip and kermit will begin to work correctly >(the error messages do not appear). > >There doesn't appear to be any way to predict how long I will have >to wait. Sometimes even powering off the machine and restarting it >does not prevent the error message from occuring. > >I am using a Mac II serial-to-modem cable and I'm using an external >Everex 24E+ (2400 baud) modem (Hayes compatible). > >The relevant entries in /etc/remote are as follows: > >dial2400|2400 Baud Hayes attributes:\ > :dv=/dev/cua:br#2400:at=hayes:du: >UNIX-2400|2400 Baud dial-out to another UNIX system:\ > :el=^U^C^R^O^D^S^Q@:ie=#%$:oe=^D:tc=dial2400: >utmicom|UT Austin Dial-in line:pn=@:tc=UNIX-2400: > >The relevant entries in /etc/ttys are as follows: > >ttya "/usr/etc/getty std.2400" unknown off secure >ttyda "/usr/etc/getty D2400" dialup on > >Can anyone suggest a solution? Is there a way to manually recycle >the port? (hopefully there is a solution that doesn't require continued >manual intervention) > >BTW, no one else is using the machine when these messages occur. > >Thanks. >-- >John Garnett > University of Texas at Austin >garnett@cs.utexas.edu Department of Computer Science > Austin, Texas Apologies for including the entire original post, but the whole thing is relevant. Modem problems abound because of the use of three different special files in the /dev directory to refer to the same physical port. For example, /dev/ttya For local terminal connection /dev/ttyda For connection to modem /dev/cua For uucp, tip/cu dialout all refer to serial port `A' on the back of the machine. Earlier posts in this newsgroup have contained a complete set of references in the NeXT manuals to find out more, but I learned the most from the zs(4) man page and from Appendix F (the UUCP section) of the System Reference Manual. Both of these sources can be found on-line in a `vanilla' 1.0 system. If you're trying to set up your cube to allow just outgoing calls, then you can forget about /dev/ttya and /dev/cua. In John's case, he should probably set the `dv' macro in /etc/remote to point to /dev/ttyda, and turn off the ttyda port in /etc/ttys. This will allow tip/cu to use the `A' port for outgoing calls -- and a Mac modem cable will work fine for this. If, however, you want to be able to receive incoming calls on port A, >and< you would like to occasionally override getty to allow a process to dial out, then you should use the /dev/cua interface to port A. In the 1.0(a) distribution, the perms for /dev/cua are set mode 600, owner uucp. This is cool as long as uucp owns the process that is trying to open the port. But if it's you, instead, trying to have a kermit or tip session, then you won't be able to open the port and both tip and kermit will report that the device is `busy' -- couldn't be opened. To fix this, set the perms for /dev/cua to mode 666. This allows processes owned by users other than uucp to open the port for read/write. Oh, by the way, if you are using /dev/cua because you want to receive calls on the same port as well as send calls, then you should be using a modem cable that matches the pinouts shown in the zs(4) man page. It seems that some `Mac modem cables' have DCD tied to CTS; others don't. Some places are already stocking/selling NeXT modem cables (Businessland part number 235739), or you can hack your own if you're handy with a soldering iron. I don't know if any of this has changed in 2.0. -- Chris Bradley | "I confess freely to you, I could never look Businessland Advanced Systems | long upon a monkey, without very mortifying Dallas, Texas US | reflections." cbradley@blackbox.lonestar.org | -- WILLIAM CONGREVE 1670-1729
rca@cs.brown.edu (Ronald C.F. Antony) (12/01/90)
In article <1990Nov23.032248.11353@blackbox.lonestar.org> cbradley@blackbox.lon\ estar.org (Chris Bradley) writes: > /dev/ttya For local terminal connection > /dev/ttyda For connection to modem > /dev/cua For uucp, tip/cu dialout >all refer to serial port `A' on the back of the machine. Earlier >[...] >If you're trying to set up your cube to allow just outgoing calls, then >you can forget about /dev/ttya and /dev/cua. In John's case, he >should probably set the `dv' macro in /etc/remote to point to /dev/ttyda, >and turn off the ttyda port in /etc/ttys. This will allow tip/cu to >use the `A' port for outgoing calls -- and a Mac modem cable will work >fine for this. >If, however, you want to be able to receive incoming calls on port A, >>and< you would like to occasionally override getty to allow a process >to dial out, then you should use the /dev/cua interface to port A. >In the 1.0(a) distribution, the perms for /dev/cua are set mode 600, >owner uucp. This is cool as long as uucp owns the process that is >trying to open the port. But if it's you, instead, trying to have >a kermit or tip session, then you won't be able to open the port and >both tip and kermit will report that the device is `busy' -- couldn't >be opened. >To fix this, set the perms for /dev/cua to mode 666. This allows processes >owned by users other than uucp to open the port for read/write. All this is not necessary: using /dev/ttyda in /etc/ttys is enough. Having turned on /etc/ttyda does not prevent you from using /dev/cua in kermit for dial out. Thus if you want dial in and out use /dev/ttyda on in the /etc/ttys file and use /dev/cua for kermit or tip. The only thing you might need to do is change permissions on /dev/cua. Main point being: use each device for what is was designed: cua = Calling Unit A ttyda = TTY on Dialupline A Ronald ------------------------------------------------------------------------------ "The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man." G.B. Shaw | rca@cs.brown.edu or antony@browncog.bitnet