cyamamot@kilroy.jpl.nasa.gov (Cliff Yamamoto) (12/01/90)
Greetings!
Well I've been losing too much sleep over this, so after weeks of hacking
I must plea for help. The situation is...
I'm implementing a dialback procedure. When people dial in to the USR HST
Dual, no problem. The gettytab is perfect, the autobaud works and everyone
can cycle throught different baud rates due to the 'nz' entry. The modem
DCE follows the baud rate and I've made the gettytab autobaud to prevent
flow problems (this is not the problem - works great). This is on a SS+
running 4.1 with the eeprom settings of 'ttyb-rts-dtr-off=false and
'ttyb-ignore-cd=false'.
Dialback is the headache. As soon as the modems connect (after dial back
and establishing carrier), the Sun drops DTR and kills the connection! The
quick fix? Disable DTR monitor on the USR so the modem ignores the DTR.
Sure it works, but now the modem doesn't hang up on logouts. The users
must manually hang up their end.
What I've found... With a 232 protocol analyzer as soon as CD goes high
(for carrier detect) the sun drops DTR. I've tried the breakout box, but
I'd like to keep the RTS/CTR and DSR/DTR stuff kosher.
** ASSUMPTIONS HERE **
My understanding is getty will always drop DTR whenever it's parent process
terminates (such as after a logout). I also understand that using termio
(in the dialback program) I can clear the HUPCL flag and prevent the modem
from hanging up when I close the device and terminate the dialback process.
So my code fragment looks like this: (with some comments added by me).
sprintf(devname,"%s%d",DIALDEV,line);
acufd = open(devname, O_RDWR); /* open device */
sleep(5); /* pause for getty to get out of the way */
ioctl(acufd, TCGETS, &s);
s.c_iflag = (BRKINT | ICRNL | IXON | ISTRIP);
s.c_oflag = (OPOST | ONLCR | XTABS);
s.c_cflag = (speedval | CS7 | CREAD | PARENB);
s.c_lflag = (ISIG | ICANON);
ioctl(acufd, TCSETS, &s);
printf("%s: dialing...\n",progname);
if (!dial(number)){ /* successful dial */
printf("%s: dial succeeded\n",progname); <<==-- I can always dial ok
ioctl(acufd, TCGETS, &s);
s.c_cflag &= (~HUPCL); <<==-- does this stop getty from dropping me?
ioctl(acufd, TCSETS, &s);
} else {
printf("%s: dial failed\n", progname);
}
close(acufd);
unlink(lockname);
}
So how do I know getty is my HEADACHE???!?
- Because when I comment out the /usr/etc/getty entry for the modem (ttyd0)
in /etc/ttytab, then my modem connects and never drops carrier (of course
there is no autobaud and login prompt).
- Becuase when I modify the code above and sleep() for several seconds just
before the 'close(acufd)' statement, the modem doesn't drop carrier until
the dialback program does a close on the device.
Have I missed anything? I'm I doing something wrong in the program? Dial
in is no problem, the Sun never drops the modem even after displaying the
login prompt. When the dialback program dials the modem and steps aside
after getting a connect, getty comes along and drops DTR (even *BEFORE*
the nx entry in gettytab does anything - eg. getty doesn't even perform any
speed table changes before it drops the carrier.)
Any clues or helpful hints would be appreciated! I'll summerize if there's
interest or if I can get it working somehow.
-- Cliffhotte@sunrise.in-berlin.de (Horst Laumer) (12/03/90)
cyamamot@kilroy.jpl.nasa.gov (Cliff Yamamoto) writes: >Greetings! >Well I've been losing too much sleep over this, so after weeks of hacking >I must plea for help. The situation is... >I'm implementing a dialback procedure. When people dial in to the USR HST >Dual, no problem. The gettytab is perfect, the autobaud works and everyone >[...] >Dialback is the headache. As soon as the modems connect (after dial back >and establishing carrier), the Sun drops DTR and kills the connection! The >quick fix? Disable DTR monitor on the USR so the modem ignores the DTR. >Sure it works, but now the modem doesn't hang up on logouts. The users >must manually hang up their end. >What I've found... With a 232 protocol analyzer as soon as CD goes high >(for carrier detect) the sun drops DTR. I've tried the breakout box, but >I'd like to keep the RTS/CTR and DSR/DTR stuff kosher. >So how do I know getty is my HEADACHE???!? I had the same problem on Dial-In with my 386-box running ISC. After missing quite as much sleep as you did, I found the reason for dropping DTR **was** getty, since this getty closes the line on an successfull open() (indicated by CD) and opens it again. Assuming your problem in an inter-system-connection, (a) try another getty (f.e. xgetty, which is PD and has an option **not** to close the line on successfull open()), (b) install it on either side of the line. Another idea would be to use a port **without** modem-control for dial-out and let the modem close the line on loss of either carrier or DTR. Hope this helps you. (I do not post the xgetty-sources, 'cause the archive is of 68 kB) sincerely HL -- ============================================================================ Horst Laumer, Kantstrasse 107, D-1000 Berlin 12 ! Bang-Adress: Domain: hotte@sunrise.in-berlin.de ! Junk-Food for Autorouters Bang: ...unido!fub!geminix!sunrise!hotte ! -- me --
cyamamot@kilroy.Jpl.Nasa.Gov (Cliff Yamamoto) (12/03/90)
In article <A5VLN1@sunrise.in-berlin.de> hotte@sunrise.in-berlin.de (Horst Laumer) writes: >cyamamot@kilroy.jpl.nasa.gov I wrote: >>So how do I know getty is my HEADACHE???!? > >I had the same problem on Dial-In with my 386-box running ISC. After >missing quite as much sleep as you did, I found the reason for dropping >DTR **was** getty, since this getty closes the line on an successfull >open() (indicated by CD) and opens it again. Assuming your problem in >an inter-system-connection, (a) try another getty (f.e. xgetty, which >is PD and has an option **not** to close the line on successfull open()), > >(I do not post the xgetty-sources, 'cause the archive is of 68 kB) > >Horst Laumer, Kantstrasse 107, D-1000 Berlin 12 ! Bang-Adress: Can Horst or anyone else direct me to the archives or a FTP site that has the xgetty source? Thanks, Clifford Yamamoto