gnu@hoptoad.uucp (John Gilmore) (05/15/87)
In article <703@unccvax.UUCP>, cbenda@unccvax.UUCP (carl m benda) writes: > a Hayes modem to be dialed from a remote pc. The problem was that after > connection had been established, kermit (on the server side) neglected to > send the modem (on the server side) the proper connection established ack- > nowledgement signal, and so the modem (on the server side) dropped the call. > > What you should do is try and figure out what your Hayes 2400 wants to receive > from YOUR machine, after it answers the phone. If a modem needs to receive something from the host to answer a call, it is broken. Modems have been used to simply receive calls since they have existed. The earliest modems would pulse Ring Indicate on the RS232 and would expect you to come back with DTR if you wanted the call answered. Nowadays they just answer when it rings, if DTR is on (maybe they did back then too). But the whole idea of sending commands down the serial line is a very new one -- in fact, Bizcomp and Hayes and USR are fighting over whether it is patentable or not. My 4 USR 2400's answer the phone just fine without my having to send 'em any commands. Personally I've had a lot of trouble getting 2400 baud dialins to work with my Sun Unix 3.3 machine. My system defaults to assuming that you have called in at 1200 baud, so if you call in at 2400 you have to send a BREAK. (I've heard that there is a getty at Berkeley, or in 4.3, that listens to the Hayes/USR response code which is sent before they raise carrier detect, that says "CONNECT 1200" or "CONNECT 2400" or the numeric equivalent, and sets the baud rate appropriately. I sure wish I could get a copy of that!) My problems are that after the BREAK, if you are lucky you get a "hoptoad login: " prompt, but then if you just hit return, it switches baud rates (to 300, then 1200, then 2400 again). On the other hand, if you type alphabetics (e.g. "foo"), it sticks at 2400 baud and prompts you for a password. I have no idea why hitting return doesn't work, but Sun was uninterested in (or unable to) find out why, and I don't have sources. I don't think it's a Sun-specific problem, since when gatech switched to 2400 baud modems I had the same trouble with them (on a Vax). Maybe the modems are particularly sensitive to the CR and don't send it out with proper framing if it's the first thing after a BREAK. (Unix detects that BREAK was hit by assuming that any framing error is a BREAK -- this should also be fixed, on machines with SCC's which know a break from a framing error.) I don't know, but it's spooky and if somebody from Netland can explain I'll be grateful. -- Copyright 1987 John Gilmore; you may redistribute only if your recipients may. (This is an effort to bend Stargate to work with Usenet, not against it.) {sun,ptsfa,lll-crg,ihnp4,ucbvax}!hoptoad!gnu gnu@ingres.berkeley.edu
dave@runx.ips.oz (Dave Horsfall) (05/22/87)
re fighting over > whether it is patentable or not. My 4 USR 2400's answer the phone just fine > without my having to send 'em any commands. Then again, I get annoyed when making several expensive phone calls to remote machines, hearing the answer tone, then zilch. If the machine has crashed or is turned off, the modem doesn't know this, and quite happily answers the phone for you. Having the machine tell the modem to "go ahead and answer it, I'm ready" has its advantages. I once chewed the hell out of one of our suppliers (in my previous job) because they got into the habit of turning off their machine (half a world away) without busy-ing out the modem. ISD phone calls are expensive. What do people out there do? Or maybe we use different modems here. -- Dave Horsfall (VK2KFU) ISD: +61 2 438-3544 FAX: 439-7036 UNIX Technical Support STD: (02) 438-3544 TLX: AA27411 NEC Information Systems Aust. ACS: dave@astra.necisa.oz (also CSNET) 3rd Floor, 99 Nicholson St ARPA: dave%astra.necisa.oz@seismo.css.gov St. Leonards NSW 2064 UUCP: {enea,hplabs,mcvax,prlb2,seismo, \ AUSTRALIA ubc-vision,ukc}!munnari!astra.necisa.oz!dave "Welcome back my friends to the show that never ends" - E.L.P.
csg@pyramid.UUCP (Carl S. Gutekunst) (05/24/87)
In article <913@runx.ips.oz> dave@runx.ips.oz (Dave Horsfall) writes: >Then again, I get annoyed when making several expensive phone calls to >remote machines, hearing the answer tone, then zilch. If the machine >has crashed or is turned off, the modem doesn't know this, and quite >happily answers the phone for you. That is what DTR is for. If the machine dies (particularly if it loses power) the DTR signal to the modem should fall, and the modem will not answer calls. Installations that botch DTR are widespread, either becuase the serial port is too limited, the software is weak, the cable was built incorrectly (using only pins 2, 3, and 7 is not enough for a modem), or the modem is misconfigured. Of course, it is much easier to fix the installation to handle DTR correctly than it is to modify the login routine to interact with the modem. <mplr
roy@phri.UUCP (05/25/87)
In article <913@runx.ips.oz> dave@runx.ips.oz (Dave Horsfall) writes: > I get annoyed when making several expensive phone calls to remote > machines, hearing the answer tone, then zilch. If the machine has > crashed or is turned off, the modem doesn't know this, and quite happily > answers the phone for you. I think we're talking about two different things. On the one hand, we have commands -- characters sent over the RS-232 data lines which a micro in the modem interprets. This includes the "ATDT" kind of stuff familiar to anybody who's used a Hayes-style modem. On the other hand, we have modem control signals, such as DTR (Data Terminal Ready) and DSR (Data Set Ready). A (properly designed) data set won't answer an incoming call unless DTR was asserted; this is as true today as it was 20 years ago. The modem control signals are wired such (i.e. with pullup/down resistors) that if the Data Terminal (which means whatever is connected to the modem, be it a VAX or a VT-100) is turned off off, DTR is negated. The end effect is that if I turn the power off the my VAX, the modems won't answer a call, without my having to do anything specific to disable them. I believe most serial boards will also negate DTR if they see a bus reset (or init, or whatever you call it on your particular machine). Thus, if my VAX panics, when it tries to reboot and does a Unibus reset, all the modem lines get disabled until /etc/init explicitly re-enables them. If for some reason the machine can't reboot itself, the modem won't answer calls until somebody comes and manually fixes things up. It is of course possible for the system to get wedged in such a state that DTR is left asserted even though nothing is running. In this situation, the modems will answer the phone and you will get nothing. Once carrier is established, the modems are perfectly happy to keep the line open forever, regardless of the fact that the machines at the two ends are not doing anything. Fortunately, this doesn't happen often. You could prevent this last case by having a watch-dog timer running on the serial line controller board -- if the CPU doesn't reset the timer every whatever (O(1 minute) seems reasonable), the board drops DTR. Of course, you want the option to disable the timer if you O/S can't deal with it, and if you opt for such a feature, you certainly want it in the serial controller, not in the modem. Modems are already too smart for their own good. Auto-dialers are nice, but in some ways the good-old 801 external dialer had the upper edge. -- Roy Smith, {allegra,cmcl2,philabs}!phri!roy System Administrator, Public Health Research Institute 455 First Avenue, New York, NY 10016
sl@van-bc.UUCP (05/27/87)
In article <2726@phri.UUCP> roy@phri.UUCP (Roy Smith) writes: >In article <913@runx.ips.oz> dave@runx.ips.oz (Dave Horsfall) writes: >> I get annoyed when making several expensive phone calls to remote >> machines, hearing the answer tone, then zilch. If the machine has >> crashed or is turned off, the modem doesn't know this, and quite happily >> answers the phone for you. > > I think we're talking about two different things. On the one hand, >we have commands -- characters sent over the RS-232 data lines which a >micro in the modem interprets. This includes the "ATDT" kind of stuff >familiar to anybody who's used a Hayes-style modem. > > On the other hand, we have modem control signals, such as DTR (Data >Terminal Ready) and DSR (Data Set Ready). A (properly designed) data set >won't answer an incoming call unless DTR was asserted; this is as true >today as it was 20 years ago. The modem control signals are wired such The simplest way to handle this for a Hayes type modem is to make sure it does not have auto answer on (ATS0=0). A simple modem watching program can monitor for RING, send ATA, then wait for CONNECT, and get the SPEED. It then execs to getty with the proper speed. It also watches for uucp/cu LCK files so uucp/cu can use the line as long as no one is actually logged in. The reason for explicitly answering the phone (so to speak) is for additional security. Your modem will not answer the call UNLESS the mgetty (my modem program) tells it to. Hanging logins are secure against people phoning in. The mgetty program can also log out people who have not typed anything for N minutes. Another plus of this system is not having to worry about people using break to get the proper speed with 2400 bps modems. -- Stuart Lynne ihnp4!alberta!ubc-vision!van-bc!sl Vancouver,BC,604-937-7532
dave@runx.ips.oz (Dave Horsfall) (05/31/87)
Perhaps I should have been more explicit in my response (sigh!). I was basically griping about the DTE's that DO NOT HAVE MODEM SIGNALS on them, hence DTR is left strapped high. Yes - they are obsolete in this day and age. But yes - they do exist, on relatively "recent" products too. -- Dave Horsfall (dave@astra.necisa.oz, despite what it says above)