carroll@bcsaic.UUCP (Jeff Carroll) (02/14/90)
I have a modem on a serial port on my System V/386 box which I would like to use for dialout as well as dialin. getty works fine, in the usual expected way, but when I edit /etc/inittab to call uugetty rather than getty, something strange happens. uugetty handles incoming calls OK, but when I try to use cu to dial out, it doesn't seem to be able to open the tty line. Running cu -d -ltty00 the system tells me "CAN'T ACCESS DEVICE". Any ideas? Jeff Carroll carroll@atc.boeing.com
rtidd@ccels3 (Randy C. Tidd w33 x6499) (02/16/90)
In article <20286@bcsaic.UUCP> carroll@bcsaic.UUCP (Jeff Carroll) writes: > > I have a modem on a serial port on my System V/386 box which I >would like to use for dialout as well as dialin. getty works fine, in >the usual expected way, but when I edit /etc/inittab to call uugetty >rather than getty, something strange happens. > uugetty handles incoming calls OK, but when I try to use cu to >dial out, it doesn't seem to be able to open the tty line. Running >cu -d -ltty00 the system tells me "CAN'T ACCESS DEVICE". I wish I could help you, but I can only agree with you. I normally use kermit to dial out, and when I have uugetty running on my serial port kermit will run fine, but when I tell it to connect to the tty it just hangs... no error message or anything, it just freezes. > Any ideas? Any ideas? Randy Tidd rtidd@mwunix.mitre.org #define DISCLAIM TRUE
kdq@demott.COM (Kevin D. Quitt) (02/17/90)
In our Systems file is the line: modem any direct 19200 - - - - - then, we just cu modem. kdq -- Kevin D. Quitt Manager, Software Development DeMott Electronics Co. VOICE (818) 988-4975 14707 Keswick St. FAX (818) 997-1190 Van Nuys, CA 91405-1266 MODEM (818) 997-4496 Telebit PEP last 34 12 N 118 27 W srhqla!demott!kdq kdq@demott.com
stevewa@upvax.UUCP (Steve Ward) (02/17/90)
In article <97213@linus.UUCP> rtidd@mwunix.mitre.org writes: >In article <20286@bcsaic.UUCP> carroll@bcsaic.UUCP (Jeff Carroll) writes: >> uugetty handles incoming calls OK, but when I try to use cu to >>dial out, it doesn't seem to be able to open the tty line. Running >>cu -d -ltty00 the system tells me "CAN'T ACCESS DEVICE". >I wish I could help you, but I can only agree with you. I normally use >kermit to dial out, and when I have uugetty running on my serial port >kermit will run fine, but when I tell it to connect to the tty it >just hangs... no error message or anything, it just freezes. The problem seems to be with kermit. I think it's not putting the lock file where uugetty expects to see it, or something. I have to manually turn off the uugetty to use kermit, but cu _usually_ works OK. Sometimes even turning off uugetty isn't enough, and I have to reboot with the uugetty turned off in order to make everyone happy. If someone has solved this problem for real, PLEASE PLEASE PLEASE post your solution!!!!!! Steve -- | Steve Ward Jr. appears courtesy of | stevewa@upvax.UUCP | | Univ. of Portland, Portland, OR | !tektronix!upvax!stevewa | | (insert disclaimer here) | upvax!stevewa@tektronix.TEK.COM | | --If all else fails, try: tektronix.TEK.COM!upvax!stevewa@uunet.uu.net |
lars@iclswe.UUCP (Lars Tunkrans) (02/19/90)
In article <20286@bcsaic.UUCP> carroll@bcsaic.UUCP (Jeff Carroll) writes: > > I have a modem on a serial port on my System V/386 box which I >would like to use for dialout as well as dialin. getty works fine, in >the usual expected way, but when I edit /etc/inittab to call uugetty >rather than getty, something strange happens. > uugetty handles incoming calls OK, but when I try to use cu to >dial out, it doesn't seem to be able to open the tty line. Running >cu -d -ltty00 the system tells me "CAN'T ACCESS DEVICE". > Any ideas? My inittab looks like this : 14:23:respawn:/usr/lib/uucp/uugetty -t 30 -r tty14 2400 vt100 And the Systems file: modem Never modem 2400 And the Devices file: modem tty14 - Any direct \D If this config doesn't work, you probably have a RS232 interface problem. My DRS300 wants DCD, DSR and CTS high as a condition to transmit anything on the interface. If the carrier is missing it does indeed behave as you describe. It is possible to dial in to the system without setting DCD high permanently because the carrier is raised by the incomming call. If you want to do " cu nodename " you need to do a more detailed config on a per system basis including the Dialers file. The above config allows you to connect to the modem and use its AT-commands if you are using Hayes compatible modems. ----- -- The ICL DRS6000 | Lars Tunkrans DRS Systems support Phone +46 (0)76096368. Series has the | UUCP: {uunet,mcsun,munnari,cernvax,diku,inria,prlb2,tut,ukc first UNIX System | ,unido} !sunic!iclswe!lars " History teaches us that man V Release 4 Port. | does'nt learn from history " Herodotos 300 B.C.
porterg@csusac.csus.edu (Greg Porter) (02/19/90)
Do you have an entry in your your /usr/lib/uucp/Devices file? If the proper entry for the type and speed of your equipment is not there it will not work. A few examples: ACU tty01 - 2400 att2224b Direct tty00 - 9600 direct -- | Greg Porter | UUCP: ..ucdavis!csusac!porterg -OR- | | CSU, Sacramento | ..ames!pacbell!sactoh0!csusac!porterg | | (916) 278-4734 | INTERNET: porterg@csusac.csus.edu |
fk@kos.rci.dk (Fleming Kraglund) (02/20/90)
carroll@bcsaic.UUCP (Jeff Carroll) writes: > I have a modem on a serial port on my System V/386 box which I >would like to use for dialout as well as dialin. getty works fine, in >the usual expected way, but when I edit /etc/inittab to call uugetty >rather than getty, something strange happens. > uugetty handles incoming calls OK, but when I try to use cu to >dial out, it doesn't seem to be able to open the tty line. Running >cu -d -ltty00 the system tells me "CAN'T ACCESS DEVICE". > Any ideas? This error usally occurs when the owner of /dev/tty00 isn't uucp <fk
olapw@olgb1.oliv.co.uk (Tony Walton) (02/21/90)
In article <20286@bcsaic.UUCP> carroll@bcsaic.UUCP (Jeff Carroll) writes: > > I have a modem on a serial port on my System V/386 box which I > would like to use for dialout as well as dialin. getty works fine, [but] > uugetty doesn't seem to be able to open the tty line. Running > cu -d -ltty00 the system tells me "CAN'T ACCESS DEVICE". It might be the ownership on /dev/tty00 - cu runs setuid uucp, so tty00 should be 622 mode *and owned by uucp* On your cu -d output, do you get blahblahblah... mlock tty00 succeeded generic open failed, errno = 13 more blahblahblah If so, that's your problem (errno 13 is EACCES - ie "permission denied"). If that's the case, just chown uucp /dev/tty00 and it should be OK. -- Tony Walton, OEM/VAR Division, British Olivetti Ltd., 154-160 Upper Richmond Rd, LONDON, SW15 2FN. Tel: (+44) 1 789 6699 Telefax: (+44) 1 785 6670 Telex:27258 Uucp : { ukc!uel | mcvax!olnl1 | ihnp4!cuuxb | iconet | olhqma } !olgb1!olapw olapw@olgb1.oliv.co.uk
bgo@PacBell.COM (Bud Odekirk) (02/21/90)
In article <20286@bcsaic.UUCP> carroll@bcsaic.UUCP (Jeff Carroll) writes: > > I have a modem on a serial port on my System V/386 box which I >would like to use for dialout as well as dialin. getty works fine, in >the usual expected way, but when I edit /etc/inittab to call uugetty >rather than getty, something strange happens. > uugetty handles incoming calls OK, but when I try to use cu to >dial out, it doesn't seem to be able to open the tty line. Running >cu -d -ltty00 the system tells me "CAN'T ACCESS DEVICE". I have Interactive Unix (System V 3.2) and I am having the identical problem. I called the Interactive Hotline (1-800-344-3896) and they are sending me a fix (X5 update) that is supposed to correct the problem. \*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\ 2600 Camino Ramon, Room 3W600E San Ramon, Ca. 94583 415 823-1379 {att,bellcore,sun,ames,pyramid}!pacbell!pbhya!bgo /\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\
ggw@wolves.uucp (Gregory G. Woodbury) (02/23/90)
In article <1061@upvax.UUCP> stevewa@upvax.UUCP (Steve Ward) writes: >The problem seems to be with kermit. I think it's not putting the lock file >where uugetty expects to see it, or something. I have to manually turn off >the uugetty to use kermit, but cu _usually_ works OK. Sometimes even turning >off uugetty isn't enough, and I have to reboot with the uugetty turned off in >order to make everyone happy. > >If someone has solved this problem for real, PLEASE PLEASE PLEASE post your >solution!!!!!! The kermit makefile is full of all sorts of interesting things. The ckutio.c file has a define for HDBUUCP (or something like that, I'm to lazy to look right now ;-) that takes care of having the lock files placed in the correct place (/usr/spool/locks) and with the correct format (pid of the locking process as an ascii string). There is a make bsdhdb target that turns on this define, but last version of kermit I got from columbia did NOT have a similar s5r3hdb and the s5r3 did not define it. System V Release 3.1 made HoneyDanBer UUCP the default and decided to call it BNU (Basic Network Utilities). Some vendors of S5R3.1 removed BNU/HDB from the basic system and make it an extra cost option. All that is necessary is to add an s5r3hdb target to the kermit makefile which defines the necessary symbol and rebuild kermit. I use kermit all the time on my V2.0.1 system and the uugetty works fine as long as the line permissions are ok. The one other thing to check is to make sure that the cable between the modem and the serial port correctly supports DTR! If not, you will have problems with the line and turnaround. -- Gregory G. Woodbury Sysop/owner Wolves Den UNIX BBS, Durham NC UUCP: ...dukcds!wolves!ggw ...dukeac!wolves!ggw [use the maps!] Domain: ggw@cds.duke.edu ggw@ac.duke.edu ggw%wolves@ac.duke.edu Phone: +1 919 493 1998 (Home) +1 919 684 6126 (Work) [The line eater is a boojum snark! ] <standard disclaimers apply>
cbp@icc.com (Chris Preston) (02/24/90)
In article <1990Feb19.052909.24336@csusac.csus.edu> porterg@csusac.UUCP (Greg Porter) writes: > >Do you have an entry in your your /usr/lib/uucp/Devices file? If the >proper entry for the type and speed of your equipment is not there it >will not work. A few examples: > >ACU tty01 - 2400 att2224b >Direct tty00 - 9600 direct >-- Having read a dozen or more articles on this thread, and having sent mail to the original source of the question, maybe a followup is appropriate. There is a problem with uugetty in some versions of System V 3.2 (under various other version names) by various vendors. Some uugetty versions apparently have problems with some types of modems (e.g. Avatex 2400). The solution we implemented was to get a PD program called modem-ctl, Volume 15, Issue 10. It replaces uugetty altogether. We have been using it for about six months and have had no problems dialing in or out using uucp/cu/kermit/younameit. It also has a timeout feature that alows disconnection after a given period of inactivity. The author's last known (to us) posting follows: [Reposted without permission of the author becuause I have no idea how to contact him] -------------------------------------------------------------------------------- >Submitted-by: Dave Settle <No net address> >Posting-number: Volume 15, Issue 10 >Archive-name: modem-ctl >[ Seems oriented toward System V-oid machines... --r$ ] > > I'm submitting the new version of 'modem', a program >to allow a line connected to a modem to be used for bi-directional >uucp/cu accesses. > > It functionally replaces 'uugetty', but provides a more sophisticated >method of talking to intelligent modems, which can screw up uugetty by >talking too much. > > The new version now has support for hardware DCD detection, which >allows the shell to be hungup when the line is dropped. > >Cheers, > Dave. -------------------------------------------------------------------------------- Hope this helps. cbp Disclaimer: --al knows tofu! Hiya --al!