amos@nsta.UUCP (Amos Shapir) (08/06/87)
One of the optional flags of the c_cflag field of termio is CLOCAL. (see
<termio.h>) It is supposed to cause the tty driver to ignore the
'carrier detect' bit in the RS232 interface, and open the line anyway.
This is needed for ports that do not have the DC wired; trying to open
such a port without setting the CLOCAL bit first, will cause the open to
hang forever waiting for a carrier signal.
However, the only way to set this flag is by a ioctl call; the ioctl
call needs a file-descriptor argument; a file-descriptor can only be
obtained by a successfull open call...
The only solution if you don't have sources is to re-wire all your
terminal plugs by shorting CD to DTR or something like that.
--
Amos Shapir (My other cpu is a NS32532)
National Semiconductor (Israel)
6 Maskit st. P.O.B. 3007, Herzlia 46104, Israel Tel. +972 52 522261
amos%nsta@nsc.com @{hplabs,pyramid,sun,decwrl} 34 48 E / 32 10 Nguy%gorodish@Sun.COM (Guy Harris) (08/07/87)
> However, the only way to set this flag is by a ioctl call; the ioctl > call needs a file-descriptor argument; a file-descriptor can only be > obtained by a successfull open call... From the S5R2 manual page OPEN(2): When opening a file associated with a communication line: If O_NDELAY is set: The open will return without waiting for carrier. If O_NDELAY is clear: The open will block until carrier is present. Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com
rmr@sdcsvax.UCSD.EDU (Robert Rother) (08/07/87)
In article <325@nsta.UUCP> amos%nsta@nsc.com (Amos Shapir) writes: >One of the optional flags of the c_cflag field of termio is CLOCAL. (see ><termio.h>) It is supposed to cause the tty driver to ignore the >'carrier detect' bit in the RS232 interface, and open the line anyway. >This is needed for ports that do not have the DC wired; trying to open >such a port without setting the CLOCAL bit first, will cause the open to >hang forever waiting for a carrier signal. > >However, the only way to set this flag is by a ioctl call; the ioctl >call needs a file-descriptor argument; a file-descriptor can only be >obtained by a successfull open call... > >The only solution if you don't have sources is to re-wire all your >terminal plugs by shorting CD to DTR or something like that. The solution is to open the file with the O_NDELAY bit set (eg. fd = open(file, O_RDWR | O_NDELAY)). O_NDELAY allows the open to complete without waiting for carrier. Next, do a TCGETA ioctl to get the current settings (ioctl(fd, TCGETA, &term)), turn on the CLOCAL flag (term.c_flag |= CLOCAL) and do a TCSETA ioctl. Now the port is open and modem control lines will be ignored. -------------------------------------------- Robert (ain't got no cute sayings in my signature) Rother rmr@sdcsvax.UCSD.EDU or sdcsvax!rmr
perry@hpfcdc.HP.COM (Perry Scott) (08/07/87)
Try opening the tty file with the FNDELAY mode flag set.
Perry Scott
..{ihnp4,hplabs}!hpfcla!perry-samos@nsta.UUCP (Amos Shapir) (08/07/87)
Specifying O_NDELAY solves the problem for one process, but it does not
help if one does not have the source; some system programs that do their
own ioctl's (most notably, /etc/getty), will let you specify some of the
ioctl flags according to your local configuration, but not the open
flags.
The problem essentially is: How do you convince getty to open a port
without waiting for carrier, if you do not have the carrier signal
wired, and your terminal driver expects to see it before proceeding? (I
do not claim there is no way, I'm rather new to sys V.3).
--
Amos Shapir (My other cpu is a NS32532)
National Semiconductor (Israel)
6 Maskit st. P.O.B. 3007, Herzlia 46104, Israel Tel. +972 52 522261
amos%nsta@nsc.com @{hplabs,pyramid,sun,decwrl} 34 48 E / 32 10 Nslb@boole.acc.virginia.edu (sandy) (08/07/87)
In article <325@nsta.UUCP> amos%nsta@nsc.com (Amos Shapir) writes:
.One of the optional flags of the c_cflag field of termio is CLOCAL. (see
.<termio.h>) It is supposed to cause the tty driver to ignore the
.'carrier detect' bit in the RS232 interface, and open the line anyway.
.This is needed for ports that do not have the DC wired; trying to open
.such a port without setting the CLOCAL bit first, will cause the open to
.hang forever waiting for a carrier signal.
You can open the line with the O_NDELAY flag set meaning return without
waiting for carrier (for a communications line anyway) and then issue
the ioctl to set CLOCAL.
sandy
--
sandy bryant
slb@virginia.edu
uunet!virginia!slbdjg@nscpdc.NSC.COM (Derek J. Godfrey) (08/07/87)
[] In article <325@nsta.UUCP>, amos@nsta.UUCP (Amos Shapir) writes: > One of the optional flags of the c_cflag field of termio is CLOCAL. ......... > However, the only way to set this flag is by a ioctl call; the ioctl > call needs a file-descriptor argument; a file-descriptor can only be > obtained by a successfull open call... > open the device once FNDELAY set CLOCAL and then open normaly or as you suggest supply DCD and DSR (and CTS).
jhc@mtune.ATT.COM (Jonathan Clark) (08/07/87)
In article <325@nsta.UUCP> amos%nsta@nsc.com (Amos Shapir) writes:
:One of the optional flags of the c_cflag field of termio is CLOCAL ...
: ... cause the tty driver to ignore the >'carrier detect' bit in RS232
:
:However, the only way to set this flag is by a ioctl call; the ioctl
:call needs a file-descriptor argument; a file-descriptor can only be
:obtained by a successfull open call...
Precisely. And to obtain such a file descriptor one should use an open()
with the O_NDELAY flag set. You are referred to the open(2) man page for
further enlightenment.
--
Jonathan Clark
[NAC,attmail]!mtune!jhc
An Englishman never enjoys himself except for some noble purpose.jfh@killer.UUCP (The Beach Bum) (08/08/87)
In article <325@nsta.UUCP>, amos@nsta.UUCP writes: > One of the optional flags of the c_cflag field of termio is CLOCAL. (see > <termio.h>) It is supposed to cause the tty driver to ignore the > 'carrier detect' bit in the RS232 interface, and open the line anyway. > > However, the only way to set this flag is by a ioctl call; the ioctl > call needs a file-descriptor argument; a file-descriptor can only be > obtained by a successfull open call... there is a flag (least ways in system V there is a flag ...) in fcntl.h named O_NDELAY that causes the open to not wait, and if i remember the documentation correctly, one of the uses given is opening a port that doesn't have DSR or DCD asserted yet. i have used this approach on our p/60 and p/95, and it works on them. as they say, "your mileage may vary ..." also, i seem to remember that some of the cu(1)'s i've seen have a no-wait flag (i recall it is used for dialing out on modems since DCD wouldn't have been asserted yet. might want to try that approach. - john. -- John F. Haugh II HECI Exploration Co. Inc. UUCP: ...!ihnp4!killer!jfh 11910 Greenville Ave, Suite 600 "Don't Have an Oil Well?" Dallas, TX. 75243 " ... Then Buy One!" (214) 231-0993
guy%gorodish@Sun.COM (Guy Harris) (08/08/87)
> The problem essentially is: How do you convince getty to open a port > without waiting for carrier, if you do not have the carrier signal > wired, and your terminal driver expects to see it before proceeding? You write a program that opens a specified set of ports with O_NDELAY, issues the appropriate "ioctl", and holds them open. Then you make sure, by tweaking "/etc/gettydefs", that "getty" doesn't futz with that mode. It's a rather unattractive solution, and it may break down if somebody explicitly turns that mode off, but it's better than nothing. Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com
jfh@killer.UUCP (John Haugh) (08/08/87)
In article <326@nsta.UUCP>, amos@nsta.UUCP (Amos Shapir) writes: > Specifying O_NDELAY solves the problem for one process, but it does not > help if one does not have the source; some system programs that do their > own ioctl's (most notably, /etc/getty), will let you specify some of the > ioctl flags according to your local configuration, but not the open > flags. > > The problem essentially is: How do you convince getty to open a port > without waiting for carrier, if you do not have the carrier signal > wired, and your terminal driver expects to see it before proceeding? (I > do not claim there is no way, I'm rather new to sys V.3). Ok, failing the O_NDELAY approach, how about something typically more Unix-like. Try a kluge. Have a program (that you write) open the port, with O_NDELAY set, and then set CLOCAL, close the port and exec getty. If you get real lucky, the driver might just be nice the next time around on the open (when getty does it) and not require the O_NDELAY flag. I can't _prove_ that this is going to work since some Unix's out of my past reset the termio values to a default when you open the port. But if it don't work because the flags are being reset, then I'm sure you can come up with a clever collection of forks and what not that will ... - John. -- John F. Haugh II HECI Exploration Co. Inc. UUCP: ...!ihnp4!killer!jfh 11910 Greenville Ave, Suite 600 "Don't Have an Oil Well?" Dallas, TX. 75243 " ... Then Buy One!" (214) 231-0993
mason@tmsoft.UUCP (08/09/87)
In sys5 if you open:
x = open("/dev/ttyx",O_RDWR|O_NDELAY,0)
it will succeed even if there is no carrier on the line. This is
documented in open(2).
CLOCAL doesn't seem to do much, except determine whether a subsequent open
without the O_NDELAY will wait for carrier or not. So you do the open above,
diddle CLOCAL if you want & then you can do another open if you want to wait
for carrier. CLOCAL probably also toggles DTR. I gleaned this information
from the dialer (which I use all the time) posted by Gene Olson from
Quest Research last fall.
../Dave Mason, TM Software Associates (Compilers & System Consulting)
..!{utzoo seismo!mnetor utcsri utgpu lsuc}!tmsoft!masonnjh@root.co.uk (Nigel Horne) (08/10/87)
In article <325@nsta.UUCP> amos%nsta@nsc.com (Amos Shapir) writes: > One of the optional flags of the c_cflag field of termio is CLOCAL. (see > <termio.h>) It is supposed to cause the tty driver to ignore the > 'carrier detect' bit in the RS232 interface, and open the line anyway. > This is needed for ports that do not have the DC wired; trying to open > such a port without setting the CLOCAL bit first, will cause the open to > hang forever waiting for a carrier signal. > > However, the only way to set this flag is by a ioctl call; the ioctl > call needs a file-descriptor argument; a file-descriptor can only be > obtained by a successfull open call... > > The only solution if you don't have sources is to re-wire all your > terminal plugs by shorting CD to DTR or something like that. In fact what you do is to open the tty line with O_NDELAY set. e.g. open ("/dev/ttya", O_RDWR | O_NDELAY); -Nigel -- -- Nigel Horne, Divisional Director, Root Technical Systems. <njh@root.co.uk> G1ITH Fax: (01) 726 8158 Phone: +44 1 606 7799 Telex: 885995 ROOT G BT Gold: CQQ173
philip@axis.fr (Philip Peake) (08/10/87)
In article <325@nsta.UUCP>, amos@nsta.UUCP (Amos Shapir) writes: | One of the optional flags of the c_cflag field of termio is CLOCAL. (see | <termio.h>) It is supposed to cause the tty driver to ignore the | 'carrier detect' bit in the RS232 interface, and open the line anyway. | This is needed for ports that do not have the DC wired; trying to open | such a port without setting the CLOCAL bit first, will cause the open to | hang forever waiting for a carrier signal. | | However, the only way to set this flag is by a ioctl call; the ioctl | call needs a file-descriptor argument; a file-descriptor can only be | obtained by a successfull open call... Look at your manual, section 2, entry for 'open'. There it tells you all about the flag O_NDELAY that you can use when opening a device. Philip
mason@tmsoft.UUCP (08/10/87)
In article <1312@killer.UUCP> jfh@killer.UUCP (John Haugh) writes: :In article <326@nsta.UUCP>, amos@nsta.UUCP (Amos Shapir) writes: :> The problem essentially is: How do you convince getty to open a port :> without waiting for carrier, if you do not have the carrier signal :> wired, and your terminal driver expects to see it before proceeding? (I :> do not claim there is no way, I'm rather new to sys V.3). : :Ok, failing the O_NDELAY approach, how about something typically more :Unix-like. Try a kluge. : :Have a program (that you write) open the port, with O_NDELAY set, and :then set CLOCAL, close the port and exec getty. If you get real lucky, :the driver might just be nice the next time around on the open (when :getty does it) and not require the O_NDELAY flag. From Amos' previous postings I was rather surprised that he didn't understand in the first place. If he'd mentioned getty....ah well. Failing John's approach, try something even more Unix-like, write your own :-). There have been a couple of postings of getty's for modems (for use dialing out & in on the same line) which would have the base for what you need, but I expect National has the real getty source anyway :-). ../Dave
njh@root.co.uk (Nigel Horne) (08/12/87)
In article <163@tmsoft.UUCP> mason@tmsoft.UUCP (Dave Mason) writes: >CLOCAL doesn't seem to do much, except determine whether a subsequent open >without the O_NDELAY will wait for carrier or not. So you do the open above, CLOCAL does do something. It tells the driver to ignore modem toggles. So if you switch off your terminal you don't get logged out if CLOCAL is set, but you do get logged out if it isn't. -Nigel -- -- Nigel Horne, Divisional Director, Root Technical Systems. <njh@root.co.uk> G1ITH Fax: (01) 726 8158 Phone: +44 1 606 7799 Telex: 885995 ROOT G BT Gold: CQQ173
allbery@ncoast.UUCP (Brandon Allbery) (08/13/87)
As quoted from <325@nsta.UUCP> by amos@nsta.UUCP (Amos Shapir): +--------------- | One of the optional flags of the c_cflag field of termio is CLOCAL. (see | <termio.h>) It is supposed to cause the tty driver to ignore the | 'carrier detect' bit in the RS232 interface, and open the line anyway. | This is needed for ports that do not have the DC wired; trying to open | such a port without setting the CLOCAL bit first, will cause the open to | hang forever waiting for a carrier signal. | | However, the only way to set this flag is by a ioctl call; the ioctl | call needs a file-descriptor argument; a file-descriptor can only be | obtained by a successfull open call... +--------------- #include <termio.h> #include <fcntl.h> #include <sys/ioctl.h> ... struct termio t; int fd; if ((fd = open("/dev/tty22", O_RDWR|O_NDELAY)) == -1) { perror("/dev/tty22"); exit(1); } ioctl(fd, TCGETA, &t); t.c_cflag |= CLOCAL; ioctl(fd, TCSETAW, &t); -- Brandon S. Allbery, moderator of comp.sources.misc and comp.binaries.ibm.pc {{harvard,mit-eddie}!necntc,well!hoptoad,sun!mandrill!hal}!ncoast!allbery ARPA: necntc!ncoast!allbery@harvard.harvard.edu Fido: 157/502 MCI: BALLBERY <<ncoast Public Access UNIX: +1 216 781 6201 24hrs. 300/1200/2400 baud>> ** Site "cwruecmp" is changing its name to "mandrill". Please re-address ** *** all mail to ncoast to pass through "mandrill" instead of "cwruecmp". ***
steve@edm.UUCP (08/14/87)
In article <326@nsta.UUCP>, amos@nsta.UUCP (Amos Shapir) writes: > The problem essentially is: How do you convince getty to open a port > without waiting for carrier, if you do not have the carrier signal > wired, and your terminal driver expects to see it before proceeding? (I > do not claim there is no way, I'm rather new to sys V.3). > -- The trick is in /etc/{inittab,gettydefs}. find the line that controls your tty in inittab and check the last par for getty. Look for a line in gettydefs with the same label in the first field. Insert a 'CLOCAL' between the first and second '#' on that line. (That field defines the STTY state BEFORE you login. You might also want to insert a '-CLOCAL' between the second and third '#' (this sets the mode AFTER the 'login' message ) so that the machines can tell when one of them hangs up. -- ------------- Stephen Samuel Disclaimer: You betcha! {ihnp4,ubc-vision,seismo!mnetor,vax135}!alberta!edm!steve BITNET: USERZXCV@UQV-MTS
amos@nsta.UUCP (Amos Shapir) (08/14/87)
In article <169@edm.UUCP> steve@edm.UUCP (Stephen Samuel) writes: >The trick is in /etc/{inittab,gettydefs}. find the line that controls your >tty in inittab and check the last par for getty. Look for a line in >gettydefs with the same label in the first field. Insert a 'CLOCAL' between >the first and second '#' on that line. (That field defines the STTY state >BEFORE you login. Sorry, that's still not good enough - getty can't stty the line until it gets a valid fd from a successful open, but the open would hang! The only solution seems to have a small program open the line with NDELAY and keep it open in the background. -- Amos Shapir (My other cpu is a NS32532) National Semiconductor (Israel) 6 Maskit st. P.O.B. 3007, Herzlia 46104, Israel Tel. +972 52 522261 amos%nsta@nsc.com @{hplabs,pyramid,sun,decwrl} 34 48 E / 32 10 N
allbery@ncoast.UUCP (08/15/87)
WRT getty: if you can't find anything else, the melbourne getty for BSD is in the mod.sources archive. It's configurable via a file /etc/gettytab (?) (although, as with all Berkeley-style programs, it looks suspiciously like /etc/termcap...). One thing to watch out for is that AT&T getty-type programs must close all file descriptors and then re-open to the terminal -- I seem to remember that it uses O_RDWR on 0, 1, and 2, so you can effectively read from stdout (!). It also has to grovel in utmp and add stuff to wtmp if it exists. The proper utmp record is the LOGIN_PROCESS type (see utmp(3)). I don't think System V getty actually uses utmp(3), though...
njh@root.co.uk (Nigel Horne) (08/17/87)
In article <332@nsta.UUCP> amos%nsta@nsc.com (Amos Shapir) writes: >In article <169@edm.UUCP> steve@edm.UUCP (Stephen Samuel) writes: >Sorry, that's still not good enough - getty can't stty the line until it >gets a valid fd from a successful open, but the open would hang! Actually it's made worse in that getty does a fopen(), not a open(). Yucky huh? -Nigel -- -- Nigel Horne, Divisional Director, Root Technical Systems. <njh@root.co.uk> G1ITH Fax: (01) 726 8158 Phone: +44 1 606 7799 Telex: 885995 ROOT G BT Gold: CQQ173
agnew@trwrc.UUCP (08/18/87)
In article <166@tmsoft.UUCP>, mason@tmsoft.UUCP (Dave Mason) writes: > > There have been a couple of postings of getty's for modems (for use dialing > out & in on the same line) which would have the base for what you need, but Anyone know where I can dig up one of these? I have same problem with a DSI-32 board running SysV.2. It doesn,t support automatic call units so to call I have to overwrite inittab, kill -1 1, manually flip the carrier detect switch on the modem, CU on the direct port, and manually dial -- a real pain! UUCP uses the direct port and dials by putting the Hayes commands in the auto-login field in L.sys -- talk about kludges!!! Actually I would like to locate uucico rather than getty, but getty would be helpfull too. ucbvax!trwrb!trwrc!agnew sdcsvax!hp-sdd!trwrc!agnew hplabs!hp-sdd!trwrc!agnew
mol@dutesta.UUCP (Marcel Mol) (08/20/87)
In article <199@trwrc.UUCP> agnew@trwrc.UUCP (R.A. Agnew) writes: >In article <166@tmsoft.UUCP>, mason@tmsoft.UUCP (Dave Mason) writes: >> >> There have been a couple of postings of getty's for modems (for use dialing >> out & in on the same line) which would have the base for what you need, but > >Anyone know where I can dig up one of these? ... I'm also interested in such a getty. -- Marcel Mol | UUCP: ..!seismo!mcvax!dutrun!dutesta!mol Delft Univ. of Tech. | BITNET: ETSTMOL@HDETUD1 Fac. of Elec. Eng. The Netherlands
agnew@trwrc.UUCP (R.A. Agnew) (08/21/87)
In article <169@edm.UUCP>, steve@edm.UUCP (Stephen Samuel) writes: > The trick is in /etc/{inittab,gettydefs}. find the line that controls your > Insert a 'CLOCAL' between the first and second '#' on that line. > (That field defines the STTY state BEFORE you login. > You might also want to insert a '-CLOCAL' between the second and third '#' > (this sets the mode AFTER the 'login' message ) so that the machines can tell > when one of them hangs up. I don't know about your system, but it don't work on mine -- Zaiz SYSV.2 on a DSI-32 in a Compaq Deskpro. CU just sits and waits for CD until I force it true manually. I think this trick only works if your dialing in, not out. Secondly, getty -c doesn't like -CLOCAL. Says it's undefined. Thirdly, it wouldn't do any good anyway cause if you had to fake CD in the first place, how you gonna know when the carrier drops ???
guy%gorodish@Sun.COM (Guy Harris) (08/21/87)
> I don't know about your system, but it don't work on mine -- Zaiz SYSV.2 on a > DSI-32 in a Compaq Deskpro. CU just sits and waits for CD until I force it > true manually. > I think this trick only works if your dialing in, not out. Well, yes, but what would you expect? "getty" handles dialing in, not out. If the problem is that you have a modem that does not permanently turn carrier on in order to that "dumb" OSes can allow a process to open the port and send dialing instructions to the modem, the fault probably lies either with the dialing code that "cu" is using or with the instructions given to "cu". It *should* be able to open the port with O_NDELAY, turn on CLOCAL, do the dialing, turn CLOCAL off, and then do *another* open to wait for carrier to come up, or something like that. > Secondly, getty -c doesn't like -CLOCAL. Says it's undefined. It doesn't like "-" in front of anything. When you define modes, it starts out with all the mode bits being zero, and turns on the ones you specify. As such, there's no need to have a way of turning mode bits off; not turning them *on* is sufficient. > Thirdly, it wouldn't do any good anyway cause if you had to fake CD in the > first place, how you gonna know when the carrier drops ??? You missed the whole point. He *doesn't* want to know when carrier drops; he doesn't give a damn about CD! He wants to hook up a *local* terminal without having to tie CD high. Since the terminal would be hardwired to the machine, the status of CD is not interesting; it doesn't indicate that "the connection was dropped" because the connection doesn't *get* dropped. Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com
jfh@killer.UUCP (The Beach Bum) (08/23/87)
In article <169@edm.UUCP>, steve@edm.UUCP (Stephen Samuel) writes: > In article <326@nsta.UUCP>, amos@nsta.UUCP (Amos Shapir) writes: > > The problem essentially is: How do you convince getty to open a port > > without waiting for carrier, [ ... ] > The trick is in /etc/{inittab,gettydefs}. find the line that controls your > tty in inittab and check the last par for getty. Look for a line in > gettydefs with the same label in the first field. Insert a 'CLOCAL' between > the first and second '#' on that line. (That field defines the STTY state > BEFORE you login. > You might also want to insert a '-CLOCAL' between the second and third '#' > (this sets the mode AFTER the 'login' message ) so that the machines can tell > when one of them hangs up. once again, someone posted first and thought later. once CLOCAL is cleared and the port closed, there ain't no way i know of to open a port without using O_NDELAY if DCD isn't asserted. if you can keep CLOCAL from getting cleared, then you're fine. my 5.2 system now supports DCD on all ports, the old one didn't, so all our terminals are wired with only RcD, TxD and ground. so, if CLOCAL gets cleared, there is no way to login on that port without running a gadget to set CLOCAL. this is what i learned. once CLOCAL is set, future open()'s don't block unless some bozo clears CLOCAL. usually, loading zeroes into a struct termio is good enough to hang a port. there is no way for getty to open the port by munging on gettydefs. getty is broke in that respect. and given the fact that we didn't even wire for DCD, it can't be fixed easily. (unfortunately for me and my career, i was the one who ordered the converters - seems plexus decided that no-one uses DB-25 connectors for RS-232 anymore :-). one last thing - omitting a flag from the initial and final fields in gettydefs doesn't require a `-' in front of the name - you just omit it. john. -- John F. Haugh II HECI Exploration Co. Inc. UUCP: ...!ihnp4!killer!jfh 11910 Greenville Ave, Suite 600 "Don't Have an Oil Well?" Dallas, TX. 75243 " ... Then Buy One!" (214) 231-0993
agnew@trwrc.UUCP (R.A. Agnew) (08/25/87)
In article <26258@sun.uucp>, guy%gorodish@Sun.COM (Guy Harris) writes: > Well, yes, but what would you expect? "getty" handles dialing in, not out. > > It doesn't like "-" in front of anything. When you define modes, it starts out > > You missed the whole point. He *doesn't* want to know when carrier drops; he > No -- didn't miss point, I was responding to Steven Samuel's reply <169@edm.UUCP>, not to Amos Shapir's <326@nsta.UUCP>. My three points and your's are the same. My problem is a little different. I have a broken, binary port of System V, release 2 by ZAIAZ to a NS32032 running on a Definicon DSI-32 in a PC clone. The modem is a INTEC 1200. I don't have source and can't get support from Definicon or ZAIAZ. The port dosn't support Automatic Call Units. Rather than fix it, ZAIAZ suggests auto dialing by defining the modem port as "direct" and using the auto-log field in L.sys to pass commands to the modem. This kludge works but CU and most importantly uucico won't "connect" to the direct port unless the DSR bit is on. (Data Set Ready). When I force DSR high via a modem switch, then I can't run getty because it runs login when there is no incoming call. I can run uucp as a polled node only or as a dialout node only. To turn it around to transmit, I have to run a script "call" which puts a direct line in inittab and then does a kill -1 1. This will only work if I flip the DSR high switch on the intec on. When I want to answer, I run the "answer" script which puts a getty/respawn line in inittab and does kill -1 1, then I have to turn the DSR switch off. Now what I need is a way to turn the DSR bit on/off with software so that uucico can go either direction. I tried running the c code submitted by Brandon Allbery in <325@#nsta.UUCP> which sets clocal mode using O_NDELAY. It apparently sets clocal but after I run it CU reports "device not available". I have to shut down and reboot (20 minutes) to get the device back. Maybe I should hook DSR to DCD and then run the c program. Please help, I am desperate. Bob Agnew -- disclaimer, disclaimer, etc. ucbvax!trwrb!trwrc!agnew sdcsvax!hp-sdd!trwrc!agnew hplabs!hp-sdd!trwrc!agnew
bruce@stride.Stride.COM (Bruce Robertson) (08/25/87)
What is really needed is a device driver that has two interfaces, one that totally ignores CD (for hardwired lines and talking to modems in the outgoing direction), and one that handles CD in the "normal" way (for dialing in). There should also be an ioctl on the hardwired interface to tell it that you now want to pay attention to CD, so that when you lose your connection to the remote machine you aren't left talking to the modem, which tends to confuse naive users, and is also a security hole. There would also be an interlock, so that both interfaces could be used at once. This driver would make all the modem turnaround programs that are in abundance totally unnecessary. You simply put a getty on the dialup interface, which blocks waiting for CD, and then freely use the hardwired interface, which works since the dialup interface isn't completely open. Obviously, the dialup interface needs to avoid waking up the getty if the hardwired interface causes a CD by calling a remote system. I have such a driver for the Motorola 68681 DUART, and could be adapted to other serial chips fairly easily. I'm willing to post it if anyone is interested. We've been using it here for several years, and there are no problems with it. It *is* copyrighted by MicroSage however, so you can't use it to make money. -- Bruce Robertson bruce@stride.Stride.COM cbosgd!utah-cs!utah-gr!stride!bruce
paul@unisoft.UUCP (Paul Campbell) (08/26/87)
In article <677@stride.Stride.COM> bruce@stride.stride.com.UUCP (Bruce Robertson) writes: > >What is really needed is a device driver that has two interfaces, one >that totally ignores CD (for hardwired lines and talking to modems in >the outgoing direction), and one that handles CD in the "normal" way >(for dialing in). There should also be an ioctl on the hardwired >interface to tell it that you now want to pay attention to CD, so that >when you lose your connection to the remote machine you aren't left >talking to the modem, which tends to confuse naive users, and is also >a security hole. There would also be an interlock, so that both >interfaces could be used at once. This driver would make all the >modem turnaround programs that are in abundance totally unnecessary. >You simply put a getty on the dialup interface, which blocks waiting >for CD, and then freely use the hardwired interface, which works since >the dialup interface isn't completely open. Obviously, the dialup >interface needs to avoid waking up the getty if the hardwired >interface causes a CD by calling a remote system. I don't think that this is the answer, not because it doesn't work but because it wont work in the future. We used to use bit 8 in a minor number for enabling carrier sleeps on open but once you start writing streams based drivers (we have a System V streams line discipline) you can't have multiple open devices (with DIFFERENT minor numbers) otherwise you get two totally different stream stacks built. I guess you could do it with two seperate drivers. Our solution is a set of ioctls (supported by stty) that are remembered after the tty is closed that turn on/off modem control. Stty of course has an option that opens a device O_NDELAY. I think that the real answer to this problem is a smart gtty, maybe there could be a signal that can be delivered to a terminal process group, it would be normally ignored but gtty would catch it and give up the terminal for a period of time??? Paul (C) Copyright Paul Campbell, you only may redistribute if your recipients can. E-mail: ..!{ucbvax,hoptoad}!unisoft!paul Nothing here represent the opinion of Unisoft or any of its employees (but me). "Nuclear war doesn't prove who's right, just who's left"