dag@persoft.com (Daniel A. Glasser) (06/14/90)
We are running Interactive Unix SysVr3.2.0.2 with the (applicable) update diskettes through X7 applied on an Everex 386/25 with 4 megabytes RAM, etc... and two standard serial ports (DOS COM1 and COM2). We use /dev/acu0 for dial out (uucico, cu, and kermit) and /dev/ttyd0 has a getty set up on it, as recommended in the X6 (asy driver fix) update kit documentation. When we use kermit to access /dev/acu0 and dial out to a remote site, when the remote site hangs up the system will not send characters to the modem until the line has been closed and reopened by the local system (either leave kermit or issue the hangup command to it, then reconnect). This same behavior is exhibited by getty on /dev/ttyd0 when a login attempt fails; getty will not send characters out to the line until either a dial out attempt is made through /dev/asy0, the modem is power cycled, or the getty is killed (which closes the semi-opened /dev/ttyd0), which means that the modem will answer the phone but nobody can log in. Has anybody else seen this behavior? Has anybody solved the problem? If so, how? Thanks for "listening", Daniel A. Glasser -- Daniel A. Glasser | Persoft, Inc. | dag@persoft.com (if it works yet) "Their brains were small, and they died."
gary@ke4zv.UUCP (Gary Coffman) (06/15/90)
In article <1990Jun14.151703.18918@persoft.com> dag@persoft.com (Daniel A. Glasser) writes: >We are running Interactive Unix SysVr3.2.0.2 with the (applicable) update >diskettes through X7 applied on an Everex 386/25 with 4 megabytes RAM, etc... >and two standard serial ports (DOS COM1 and COM2). We use /dev/acu0 for >dial out (uucico, cu, and kermit) and /dev/ttyd0 has a getty set up on it, >as recommended in the X6 (asy driver fix) update kit documentation. > >When we use kermit to access /dev/acu0 and dial out to a remote site, >when the remote site hangs up the system will not send characters to the modem >until the line has been closed and reopened by the local system (either leave >kermit or issue the hangup command to it, then reconnect). This same behavior >is exhibited by getty on /dev/ttyd0 when a login attempt fails; getty will >not send characters out to the line until either a dial out attempt is made >through /dev/asy0, the modem is power cycled, or the getty is killed (which >closes the semi-opened /dev/ttyd0), which means that the modem will answer >the phone but nobody can log in. > >Has anybody else seen this behavior? Has anybody solved the problem? >If so, how? Check your modem setup. Your modem should assert CTS and DSR always and should assert DCD only when a carrier is present. getty monitors DCD and will release the line when it is false. If your modem is toggling CTS or DSR when carrier is lost, you will get the behavior you describe. Your modem should honor DTR and reset itself to stored parameters when DTR is dropped. This way you can store your modem parameters for incoming calls and then use your Dialers entry to set any parameters you need different for making outgoing calls. When the call terminates your modem will be reset to incoming state. getty can get into a pathological state if you have your modem set to echo in command mode. You will get a getty respawning too rapidly message if this happens. So make sure your stored parameters say echo off. You can turn it back on in your Dialers script for call progress monitoring if you like. Gary
jbm@celebr.uucp (John B. Milton) (06/27/90)
In article <852@mutad.UUCP> arjen@mutad.UUCP (Arjen Duursma) writes: > >+Check your modem setup. Your modem should assert CTS and DSR always and >+should assert DCD only when a carrier is present. getty monitors DCD and >+will release the line when it is false. If your modem is toggling CTS or >+DSR when carrier is lost, you will get the behavior you describe. Your >+modem should honor DTR and reset itself to stored parameters when DTR >+is dropped. This way you can store your modem parameters for incoming >+calls and then use your Dialers entry to set any >+parameters you need different for making outgoing calls. When the >+call terminates your modem will be reset to incoming state. getty >+can get into a pathological state if you have your modem set to >+echo in command mode. You will get a getty respawning too rapidly >+message if this happens. So make sure your stored parameters say >+echo off. You can turn it back on in your Dialers script for call >+progress monitoring if you like. > >Great, thats what I thought. But what to do when your >modem refuses to reset itself when DTR drops. >Switches are correct and the TR light does go out, but no reset. >Can there be some RS-232 signal crosslinks or whatever which prevents >the reset? And then there are those modems that can't (or won't) save setup parameters or can't do DTR reset/reload. I use a program I call "prtty", which is a hacked up version of a program called "modem-ctl" in the archives. This program is run by init (prtty instead of getty in /etc/inittab). You only put this program on lines that have modems. When spawned by init, it opens the port NDELAY, talks to the modem: ATZ\d\dATX1V1Q0E1L3, etc. It then sends ATS0=0 to put the modem in no-auto-answer. It then sits there waiting for the string "RING" to come in from the modem. When it does, it sends "ATA", which answers the phone. It the waits for "CONNECT", looks at the text following that and kicks off a "getty -h" at the correct baud rate. The tty line always gets set to the correct rate. If the modem does not answer, the machine is crashed or VERY VERY heavily loaded. After reading each character, prtty does an access("/usr/spool/locks/ttyxxx,0) to see if a lock file has been created. If there is a lock file, prtty immediately exits, gets respawned by init and waits for the lock file to go away. Every five tests of the lock file, it opens the lock file, reads the PID, does a kill(PID,0) to see if the process is still running. If it is, it keeps waiting. If not, it removes the lock file and starts initializing the modem. The are more details, of course. Prtty keeps a log file for each port, the verbosity determined by a startup -x switch from inittab. You can check this lock file to see if you are getting a lot of connects but no logins and also to check at what rate those connects are. I have had prtty running on a wide variety of SYSV boxes (heavy SYSV termio), with little modification (mostly lock files). The part that is constantly changed is the chat script for the particular modem. A rewrite of this beasty is somewhere on my "to-do" list, but not very high at the moment. I don't think prtty is on any of the archive sites, but I could be wrong. I've sent out a lot of copies in the mail. One of the users of prtty is using it with a Telebit Trailblazer 2500. It handles all of the incoming and outgoing modes. We need an UNmoderated group comp.sources.unix.i386 John -- John Bly Milton IV, jbm@uncle.UUCP, n8emr!uncle!jbm@osu-cis.cis.ohio-state.edu (614) h:252-8544, w:469-1990; N8KSN, AMPR: 44.70.0.52; Don't FLAME, inform!