cslater@ibmpa.UUCP (Charlie Slater) (02/14/90)
This posting describes how I set up ibmsupt's Hayes 2400 modems which receive incoming calls from IBM/4.3 customers. For outgoing calls, the default settings are fine, so if your only modem application is to call ibmsupt to download new compilers, you don't need to read this posting. Objective: Prevent unwanted chatter between the RT and the Modem How logins work: A program called "getty" prints out a banner (usually the name of the machine and the version of the operating system) and then prompts for a username with "login: ". The username is passed to /bin/login which prompts for a password. If the port is marked "on" in /etc/ttys, then getty will open and prompt for a username whenever the port is free. One does not want the modem to echo "login: " back to getty and "password: " back to login. You don't want it to say "OK" or "NO CARRIER" either, indeed even "0" and "1" could be mistaken for usernames and passwords. Therefore, people configuring a modem to accept incoming calls include the "E0Q1" in their Hayes commands. "E0" means disable echo and "Q1" means suppress result codes. The following is sufficient to configure many modems to accept incomming calls: AT&F&C1&D2S0=1E0Q1&W &F means start with factory defaults and &W means write to NVM. S0=1 means answer after one ring. The new settings which have some data communications implications are &C1 and &D2. They mean do the "right" thing with Data Carrier Detect (DCD) and Data Terminal Ready (DTR), respectively. The "right" thing for the modem to do when carrier is lost is to lower DCD. This tells the computer that the line is no longer in use and the driver sends a HUP signal to the process attached to that port. The "right" thing for the modem to do with DTR is to insist that it be there. If DTR is not asserted by the computer, the modem will not answer the phone. If the computer lowers DTR, the modem will disconnect the phone. The diagram below illustrates the concepts presented so far. ________________ |getty login sh | | | _____ | kernel |-----------|modem| | DTR |-> <-|DCD | ---------------- ----- For most modems, this is enough. For example, to configure the Telebit Trailblazer modems attached to ibmsupt, I locked the baud rate at 19.2Kbps, turned off flow control and reversed the tone search sequence so that PEP was last with this command: AT&F&S51=5S58=0S66=1S92=1 I then did the Telebit equivalent of the previously mentions Hayes command: ATS53=2S52=1S0=1E0Q1&W and I could dial this Telebit with a Hayes modem or another Telebit and things worked fine. Setting up the Hayes to accept incomming calls was not quite this simple. Even with echo and result codes disabled, the modem would chatter with the computer between the time the phone rang and the time the connection was established. This chatter caused the modem to connect at 1200 bps instead of 2400 bps. I did not know why this was happening, but I did know how to prevent it. In the config file entry for each asy controller there is a "flags" field. If flags is 0xFF, the variable asysoftCAR is set for each port on the controller and the driver will return from open right away. This is the default as shipped. If the flags is 0x00, the then asysoftCAR is not set and the driver will not return from open until carrier is present. For the controller that serves inbound modems, I changed asysoftCAR from 0xFF to 0x00. This solved the dial-in problem. (For those who are short of controllers or slots and need to do this by port: The lower four bits are used. 0x01 <==> bit 0 <==> port 0. In practice the results of 0x0F are equivalent to 0xFF.) The downside of clearing asysoftCAR is that when you want to talk to the modem when carrier is not present (e.g. you want to configure the modem or dial out), you cannot because the open call will not return. Acucntrl attempts to set or clear asysoftCAR as appropriate. I have not always had success with acucntrl, so when I need to talk to the modem, I turn getty off in /etc/ttys and turn asysoftCAR on with adb. IBM/4.3 includes online documentation for adb, asy, getty, login, and tty. Disclaimer: This posting does not imply an endorsement of either Hayes or Telebit modems. Other manufacturer's modems may work as well or better or worse in this application. I speak for myself not IBM and any errors in this posting are my responsibility. -- charlie slater uunet!ibmsupt!cslater (UUCP) cslater%ibmsupt@uunet.uu.net (Internet) cslater@ibmpa.tcspa.ibm.com (IBM internal internet)
fetrow@milton.acs.washington.edu (David Fetrow) (02/19/90)
>This chatter caused the modem to >connect at 1200 bps instead of 2400 bps. I did not know why this was >happening, but I did know how to prevent it. > One reason for chatter between a true Hayes modem and an RT runing AOS is the unfortuneate modem code ATIO, which identifies the product (it returns a number) and isn't turned off with the usual flags. The reason this is unfortuneate? The login banner includes the word "information" ^^^^ -- -dave fetrow- fetrow@bones.biostat.washington.edu dfetrow@uwalocke (bitnet) {uunet}!uw-beaver!uw-entropy!fetrow "CP/M: Remember when fast, small, useful and clean were good?"
knop@duteca (P. Knoppers) (02/20/90)
In article <2022@milton.acs.washington.edu> fetrow@milton.acs.washington.edu (David Fetrow) writes: ... some lines deleted ... > One reason for chatter between a true Hayes modem and an RT runing AOS >is the unfortuneate modem code ATIO, which identifies the product (it >returns a number) and isn't turned off with the usual flags. > > The reason this is unfortuneate? > > The login banner includes the word "information" > ^^^^ Maybe you can put a <space> <backspace> sequence between the 'a' and the 't' of the word "information". This usually stops the modem from recognizing the AT sequence. If <space> <backspace> does not work, maybe you can find another character sequence that is invisible on terminals, but hides the "AT". (Ctrl-G may not be the best choice.) Greetings from Delft, The Netherlands -- _____ __ __ __ __ ____ _____ _____ ______ _____ _____ | _ \ | |/ || \| | / \ | _ \ | _ \ | ___|| _ \ / ___| | __/ _ | < | || || || __/ | __/ | >__ | < \__ \ |__| |_| |__|\__||__|\__| \____/ |__| |__| |______||__|\__||_____/ P. Knoppers, Delft Univ. of Technology, The Netherlands, knop@duteca.tudelft.nl